Purecloud-platform-client-v2 version 160.0.0 "require is not defined"

[Boggs_Daniel]

I think the difference in mine is that I'm outputting to a library:

build: {
    lib: {
      entry: "./src/main.ts",
      fileName: () => "genesys-test.js",
      formats: ["es"],
    },
    outDir: ".",
    emptyOutDir: false,
  },

Updating charming-butterfly-3cfz27 - CodeSandbox to output to a library will also give the same issue.

Problem is, I'm trying various ways to polyfill and none of them are working. This seems to be a significant regression. (Stuck on 159 until we find a way around it.)

For version 160, there was something about a proxy that changed. What's the story behind that? Is there any other way to address it to avoid this regression?

Also, does anyone know of a way to get polyfilling to work with a library generated by vite?

I appreciate all the assistance (especially since this is due to implementation details of the library).

[Bart]

Hi all,

The dev server is working with nodePolyfills plugin. But a build results in a broken app. Same with the addition of the commonjs plugin.

To reproduce, use the same sample app from my first post.

1. Run a build:

npm run build

2. Start a nginx Docker container with the dist folder mounted:

docker run -it --rm -d -p 8080:80 --name genesys-test -v $(pwd)/dist:/usr/share/nginx/html nginx

3. Open: http://localhost:8080
4. Open console to view error, this is the same error we get on a prod build on our real stack.

We really need to be able to update in the future to use the upcoming task management .

[tim.smith]

@Boggs_Daniel

For version 160, there was something about a proxy that changed. What's the story behind that? Is there any other way to address it to avoid this regression?

Proxy support was broken and the package was updated in 160 to fix it.

@Bart

We really need to be able to update in the future to use the upcoming task management .

If you're unable to get your build system to compile a working application with the library, I would suggest the alternative approach I mentioned previously about using the package's source code directly in your app.

[Boggs_Daniel]

@John_Carnell @tim.smith
This regression is due to no fault or incompetence of our own (as has been unfortunately implied). We're using a very popular build system and not doing anything particularly interesting with it.

As a Genesys customer, we'd like for Genesys to work with us to get this library -- one of the APIs of the "API-first" Genesys Cloud product -- working again past version 159, without having to dismantle it ourselves and maintain a fork, or ditch the API completely (things no customer should be asked to do, especially when the changes that caused it have absolutely no business relevance to the customer), and without being dismissed.

Any and all efforts you can make to resolve this issue in the library would be greatly appreciated.

[Bart]

@tim.smith

If you're unable to get your build system to compile a working application with the library, I would suggest the alternative approach I mentioned previously about using the package's source code directly in your app.

You may have fixed proxy support in NodeJS, but in doing so, you unintentionally broke the package for your customers creating a web app using Vite as a build tool.

Stuff breaks, that's part of our job. But it feels a bit weird to me that the responsibility of getting the SDK working after v159 in a Vite stack is the responsibility of your customers. We're not doing anything out of spec, weird, or exotic. We're using a popular build tool with your package, which according to your own README can be used in a browser.

For me, answers like fix your build tool or maintain your own fork are not acceptable. The whole point of using Genesys and your SDK is that it is maintained by you.

[John_Carnell]

@Bart

package, which according to your own README can be used in a browser.

Hey everyone,

Let's take a step back here. I understand everyone's frustration and would be upset if suddenly something broke when nothing in my code changed. I think I need to provide some additional context:

1. The advice on using polyfill was meant to try and get everyone back working as quickly as possible. I know it's not an ideal solution. The irony here is that the original HTTP client we used in our SDK, SuperAgent, would have required you to use a polyfill, and you would have likely been faced with a similar situation.

2. We moved over to Axios last year because several of our customers were getting flagged with security vulnerabilities with SuperAgent and Axios was to be a better solution. In moving over to Axios, it turns out their proxy support was broken.

3. In fixing the proxy support we introduced this issue with Vite.

4. Let's face it, there are 100s of different Javascript frameworks and build tools out there. It is extremely difficult to regression test across all of these frameworks and frankly, none of us had even heard of Vite until last week. (Not saying Vite isn't popular, but so are React, Angular, Vue, Ember, next, meteor, polymer, and Backbone frameworks, ......... )

5. I will assign someone on my team to look at how we can resolve this, but we can not determine yet if the fix is a short-term or long-term fix or the time horizon yet on what it will take to fix the issue. Our SDK does support browsers, but it has always been based on node and has always carried with it the chance that something would break during the "transpilation" process specific to an individual customer framework/build tools choices.

6. At this point there are really two options for you in regard to working around this while we try to find a solution:

• Tracking down the problem in the Vite build process that is allowing the dev server to run, but failing on the build. We can offer limited support here because my team has not worked with Vite and it will take time to familiarize ourselves with it.

• Stay at v159 and use the ApIClient.callApi() calls for any newly added API calls until we can get this sorted out. The truth is all of our Javascript SDKs are pretty much wrappers to this particular call. You can see an example of this call being used here.

It's not a perfect solution, but it will keep you moving while we try and find a solution.

I am sorry for everyone's frustration. Javascript is not known for its easy-to-use build and deployment environments. It's all great until the magic stops working (I should know, I am a Java/Spring developer and when the magic stops working it really stops working ).

So be patient while we try to sort this out.
Thanks,
John Carnell
Director, Developer Engagement

[Boggs_Daniel]

Is there a reason the code is using "require" here instead of "import"?
This seems to be what is breaking.

[tim.smith]

@Boggs_Daniel

Is there a reason the code is using "require" here instead of "import"?

(This is an attempt at a technical explanation for this specific question, not an extension of John's post above)

It's a pragmatic approach because that's how that library expects to be included. The transpilation process to compile the source code into the desired framework format will handle normalizing import to whatever the target framework requires. If you check out the platform-client-sdk-javascript/build/dist folder, you can see the pre-transpiled versions of the SDK for node, AMD, and CJS for web. They all normalize to use require instead of import, but handle resolving that function at runtime in different ways (AMD vs web CJS).

As I'm not familiar with Vite's internal workings I'm making an assumption here, but my assumption is that Vite is not using the pre-transpiled packages in the build/dist/ folder. I assume Vite is instead using the raw source from build/src/. This isn't a problem, but is an important distinction. Because it's not using the pre-transpiled package, Vite becomes responsible for handling the transpilation tasks like normalizing import/require statements to comply with the target package format and providing node polyfills.

To bring that around to the error above about require not being defined, if Vite is failing to transpile the package appropriately and is leaving a call to the node require function without providing a polyfill for it, that would cause the function to be undefined.

[Boggs_Daniel]

Thanks.

(I initially posted a success here, but then edited after realizing I hadn't actually updated the purecloud library... sorry about that...)

So, Vite uses esbuild for its dev server, and rollup for builds. The dev server works OK, but builds aren't working, so the issue is related to rollup.

In my case, Vite is configured to prioritize the "module" setting in the package.json of libraries in node_modules. So it's looking at the sources, in the case of purecloud-platform-client-v2.

It looks like the sources have a mix of imports and requires.

I found the following Vite setting:

    build: {
        commonjsOptions: {
            transformMixedEsModules: true
        }
    }

But it unfortunately didn't resolve the issue.

We can keep digging on this until we find something.

Is it possible that the library could also distribute an "es" version in addition to the others? It looks like the genesys-cloud-webrtc-sdk library does this.

[John_Carnell]

Hi Daniel,

We will look into posting an ES version, however, I can't promise anything because we do not know the size of the work. I will tell you though that we are looking at doing the following:

1. We are looking at refactoring the APIClient, removing the direct dependency on the Axios/hpagent proxy from the core SDK.

2. What we would then do is allow a developer to inject their own Axios client with a proxy configured using the hpagent solution if they need a proxy.

3. What this will allow us to do is shift the SDK back to the previous state because if you do not inject your own Axios client, you will use the default configuration we used before and you should no longer have to mess with polyfil.

4. If you want to use a proxy at least in Node, you just need to configure the hpagent on the Axios client and pass it in.

5. This does not solve if you want to use a proxy in the client, but at that point, the dependency is out of the SDK and it would be the responsibility of the person setting up and configuring the Axios proxy to figure out how to properly transpile the build process.

I have an engineer looking at this approach. If it works, it will return you guys back to the state we were in before the v160 release and still enable the people who are using the proxy to configure the SDK to use the proxy.

Thanks,
John Carnell
Director, Developer Engagement

[Bart]

Thanks for the update, @John_Carnell. Everybody here gets that sometimes fixing one bug leads to another one, part of the job. Good to read the steps you're taking.

[Declan_ginty]

Hi all,

We have publish a new version of the Javascript SDK, version 163.0.0 and made a change to how we implement a proxy. This should fix the issues your having.

Regards,
Declan

[Boggs_Daniel]

@tim.smith @Declan_ginty @John_Carnell Thank you. This indeed resolves the issue for me. I greatly appreciate everyone's response and assistance in getting this working again for us, and for the quick turnaround.

[Bart]

We can gladly report the same, v163 is working on our Vue/Vite stack.

Thanks for the quick responses and fix.