No luck with this one either.
@Bart, did any of this work for you?
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
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".
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.
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?
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 
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
1 Like
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
@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.
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.
Understood, thanks for your answers.
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.
1 Like
I reproduced the issue I'm having here:
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.
Here's an example showing the platform client working with vite and vue per the instructions in this thread: charming-butterfly-3cfz27 - CodeSandbox. 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.
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).
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.
- Run a build:
npm run build
- 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
- Open: http://localhost:8080
- 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 .
Proxy support was broken and the package was updated in 160 to fix it.
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.
@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.
3 Likes
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.
1 Like
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:
-
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.
-
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.
-
In fixing the proxy support we introduced this issue with Vite.
-
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, .........
) -
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.
-
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
2 Likes
Is there a reason the code is using "require" here instead of "import"?
This seems to be what is breaking.
