Legacy Dev Forum Posts

Boggs_Daniel | 2023-03-09 18:42:48 UTC | #1

I'm using the javascript SDK "purecloud-platform-client-v2" version 160.0.0.

We have a react/typescript application using Vite as the build tool.

When I upgraded from 159.0.0 to 160.0.0, the app started failing to load with the error "require is not defined". See attached snapshots from Chrome dev tools.

Our app works again after downgrading to 159.0.0.

John_Carnell | 2023-03-09 19:15:41 UTC | #2

Hi Daniel,

Thanks for posting. I suspect this might be related to a fix we just implemented around our Javascript SDK proxy capabilities. I am going to have one of our team mates pulldown and build a simple React app with the SDK and see if they can figure out what it going on.

Thanks, John Carnell Director, Developer Engagement

Bart | 2023-03-14 16:06:49 UTC | #3

Same for us, v160 breaks our Vue3 / Vite stack. This is easily reproducible with this demo app:

1. Create new Vue App:

npm init vue@latest

2. Give it a name (genesys-test) and answer no to all questions.

cd genesys-test
npm install
npm install purecloud-platform-client-v2

3. Open src\App.vue in an editor and add this to the script setup:

import platformClient from 'purecloud-platform-client-v2';

const client = platformClient.ApiClient.instance;

4. Start the dev server

npm run dev

5. Open the localhost URL.
6. Open the browsers console to view the errors.

John_Carnell | 2023-03-15 15:54:02 UTC | #4

Hi guys,

We are still digging into this. We were able to update our React blueprint with Javascript version 160.0.0. of our API. It appears that this is localized to the Vite.js framework and Javascript 160. Thanks for the additional detail.

Thanks, John

Declan_ginty | 2023-03-16 16:26:02 UTC | #5

Hi Guys,

This is related to a feature of vite. Vite by default does not polyfill node modules. In version 160.0.0 of the javascript SDK we started using a new node package and it is this package that requires polyfill to be used. So for version 160 and greater of the javascript SDK with vite you will need to add a plugin to vite for polyfill. This can be done like so:

npm install vite-plugin-node-polyfills   

In your vite.config.js add the following:

import { nodePolyfills } from "vite-plugin-node-polyfills";

and also add the following to the defineConfig

plugins: [
    nodePolyfills({
      protocolImports: true,
    }),
  ]

Regards, Declan

Boggs_Daniel | 2023-03-16 17:03:03 UTC | #6

I still get the "require is not defined" error. It seems maybe more related to CommonJs.

Declan_ginty | 2023-03-16 17:17:25 UTC | #7

Hi Daniel,

I can't replicate this but it is most likely a similar feature of vite with a similar fix, try the following:

npm install vite-plugin-commonjs

and in vite.config.js add:

import commonjs from 'vite-plugin-commonjs';

and the following to your plugins:

  plugins: [
    commonjs()
  ]

Regards, Declan

Boggs_Daniel | 2023-03-16 17:29:32 UTC | #8

No luck with this one either.

@Bart, did any of this work for you?

davie | 2023-03-17 07:36:54 UTC | #9

Hi Declan,

Maybe we should focus on a possible different solution from Genesys, instead of trying to polyfill something that should only belong on NodeJS and not in the browser. It's not (really) a Vite problem, but it's because the package now mixes browser and node with import and requires and it shouldn't imho.

So if hpagent is not required in the web bundle, there is no issue anymore.

kind regards,

Davie

tim.smith | 2023-03-17 13:30:34 UTC | #10

Hello @davie, doing a full rewrite of the SDK from the ground up isn't something we can do in the short term, but it is a long term plan. If you intend to use the current SDK in your application, you'll need to configure its build process to provide the required node polyfills. This process can be tricky and due the nature of every JS framework and transpilation engine and even project setup being different, we cannot provide a standard set of instructions other than "provide polyfills as appropriate per your application's architecture".

Boggs_Daniel | 2023-03-17 13:47:32 UTC | #11

Can anyone else confirm that the polyfills actually do anything to solve this issue? They don't for me. Which is why I think the polyfills aren't necessarily the issue here.

All I know is that it's been working for a long time, and now it's broken.

tim.smith | 2023-03-17 13:54:03 UTC | #12

Yes, it works. I personally just followed Bart's post above to replicate the issue and got the same console output. Then I followed Declan's instructions to install vite-plugin-node-polyfills and then the app loads successfully with no errors in the console anymore. The latest SDK has also been validated using React 16, which provides node polyfills automatically.

If you're still having an issue, can you provide details?

davie | 2023-03-17 14:01:49 UTC | #13

Hi @tim.smith ,

I'm not asking Genesys for a complete rewrite of your SDK, but I'm asking to keep web for web and nodejs for nodeJS :wink:

Genesys has different builds available from your package for Node and web and now in this version there is a new dependency introduced that is of type Node (commonjs) and imho should not be in a web version of your SDK.

Since this is introduced in this recent version, which breaks code for your users who don't want to polyfill stuff, we do want a proper solution for this.

Kind regards Dave

tim.smith | 2023-03-17 14:07:09 UTC | #14

davie, post:13, topic:18824
I'm not asking Genesys for a complete rewrite of your SDK, but I'm asking to keep web for web and nodejs for nodeJS :wink:

The SDK is written for a node environment and transpiled to two web targets. What you're asking for requires starting from scratch with a different approach that doesn't begin with an SDK for node.

I'll remind everyone participating in this thread that the SDK is open source and you're allowed to use as little or as much of that source code in any way you like (up to and including simply copy/paste the parts you want into your own codebase). If you don't like the dependencies the SDK has or don't like the transpiled formats provided, you are absolutely encouraged to use the source code directly to accomplish your goals. https://github.com/MyPureCloud/platform-client-sdk-javascript

Bart | 2023-03-17 15:04:55 UTC | #16

@Boggs_Daniel I just tested on our stack and v161 works with the nodePolyfills plugin. We can upgrade, so the problem is solved, but it feels like a bit of a workaround.

I must agree with @davie, if you have two web targets, I assume one for Node.js and one for browser. I would think both targets should keep on working. The CommonJS dependency should not be in the browser target of the SDK. It was working fine before v160, so fixing the incompatibility that snuck in shouldn't require an entire rewrite. It seems this change could be the culprit.

The Vite documentation explains it here:

We recommend avoiding Node.js modules for browser code to reduce the bundle size, although you can add polyfills manually. If the module is imported from a third-party library (that's meant to be used in the browser), it's advised to report the issue to the respective library.

tim.smith | 2023-03-17 15:19:17 UTC | #17

We're aware of what caused this change; it was intentional to fix proxy support. As stated previously, the JS SDK is a node package that is transpiled for web. It has node dependencies that must be polyfilled. It is well understood that this is not desirable for a web environment. There are plans to change that architecture in the future, but rewriting the SDK is not a simple task and is not going to happen right now.

Bart | 2023-03-17 15:18:10 UTC | #18

Understood, thanks for your answers.

Bart | 2023-03-17 15:47:48 UTC | #19

Correction. The dev server is now working, but I just ran a prod build and that's still broken. Also added the commonjs vite plugin to no avail. I need to do some more research to make it reproducible. Will follow up after the weekend.

Boggs_Daniel | 2023-03-17 20:14:36 UTC | #20

I reproduced the issue I'm having here:

https://codesandbox.io/p/sandbox/loving-agnesi-l1ohf9?selection=%5B%7B%22endColumn%22%3A13%2C%22endLineNumber%22%3A3322%2C%22startColumn%22%3A13%2C%22startLineNumber%22%3A3322%7D%5D&file=%2Ftsconfig.json

I'm building it as a library (run the build to get the genesys-test.js file), and the generated code still has the requires.

Haven't figured out yet what might be causing it.

tim.smith | 2023-03-17 20:34:41 UTC | #21

Here's an example showing the platform client working with vite and vue per the instructions in this thread: https://codesandbox.io/p/sandbox/charming-butterfly-3cfz27?file=%2Fpackage.json&selection=%5B%7B%22endColumn%22%3A47%2C%22endLineNumber%22%3A21%2C%22startColumn%22%3A47%2C%22startLineNumber%22%3A21%7D%5D. I've never used either before, so I don't have any troubleshooting steps to recommend, but maybe an example that isn't crashing will help.

Boggs_Daniel | 2023-03-17 22:01:52 UTC | #22

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 https://codesandbox.io/p/sandbox/charming-butterfly-3cfz27?file=%2Fpackage.json&selection=%5B%7B%22endColumn%22%3A47%2C%22endLineNumber%22%3A21%2C%22startColumn%22%3A47%2C%22startLineNumber%22%3A21%7D%5D 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 | 2023-03-20 09:47:17 UTC | #23

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 | 2023-03-20 13:18:27 UTC | #24

Boggs_Daniel, post:22, topic:18824
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.

quote="Bart, post:23, topic:18824"] We really need to be able to update in the future to use the upcoming [task management. [/quote]

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 | 2023-03-20 14:17:00 UTC | #25

@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 | 2023-03-20 15:03:56 UTC | #26

tim.smith, post:24, topic:18824
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.

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 | 2023-03-20 15:59:35 UTC | #27

Bart, post:26, topic:18824
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:
7. 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.
8. 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 :frowning: ).

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

Boggs_Daniel | 2023-03-20 16:05:28 UTC | #28

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

tim.smith | 2023-03-20 20:12:06 UTC | #29

Boggs_Daniel, post:28, topic:18824
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 | 2023-03-21 14:04:41 UTC | #30

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 | 2023-03-21 14:50:53 UTC | #31

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 | 2023-03-22 16:29:38 UTC | #32

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 | 2023-03-28 14:57:12 UTC | #33

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 | 2023-03-28 14:57:01 UTC | #34

@tim.smith @Declanginty @JohnCarnell 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 | 2023-03-29 07:54:27 UTC | #35

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

Thanks for the quick responses and fix.

John_Carnell | 2023-03-29 16:27:28 UTC | #36

This post was migrated from the old Developer Forum.

ref: 18824