ESM Solution instead of UMD?

GoJS
#1

While integrating GoJS into an internal library as part of its evaluation, we ran into an interesting issue: after deployment we found that the application consuming our library was no longer able to load. After debugging, we discovered that the underlying reason was that, despite our library being built by WebPack as a single self-contained bundle, GoJS’s UMD implementation had found the AMD loader of our parent application globalThis.define.amd and was attempting to register itself.

The application consuming our library uses Dijit’s require which, according to this forum post (GoJS with Aurelia Mismatch Error - #8 by simon), is known to not work with the UMD implementation used by GoJS. In this case, since GoJS was being bundled by WebPack, the attempt to register globally is not a desired trait. Is there a way to get an ESM-only version of GoJS, or would there be a way to add a flag that could used to avoid registering via AMD (e.g. window.skipGoJSUMD = true; )

If neither of the above two solutions would work, could the UMD implementation be updated to check globalThis.define.amd to see if the require implementation is from dijit, so it could use a named export, as dijit expects?

#2

The go-module.js (or go-debug-module.js) file is an ES module. Which file are you using?

#3

We are using go-module.js. While it is an ES Module, everything is registered with AMD first and then exported, so that’s causing us the issue. If it was all just exported then it would be fine or had someway to bypass AMD.

#4

We will look into this matter.

#5

Thank you for pointing this out. We’ll make sure it works in future versions.

If you have a simplistic case or config for your setup, that you would like us to test against, feel free to send it to us (gojs at our domain, nwoods.com). It would help to ensure that we are covering your scenario appropriately. We have not heard of someone using Dojo for some time.

It does seem like, at first glance, there is no need for us to register AMD style in our module JS file.

#6

Thanks for the quick response on this issue. Unfortunately I don’t know that I can provide a sample for you to test against since it only happens when used with a large 3rd party library that I can’t distribute. Yes, it is quite an old library to still be using dojo. They have a newer version without this problem, however the new version is very much a breaking change, so it will be a while until we have the time to allocate to updating.

We have managed a temporary work around for this issue, so it won’t hold us up once we purchase and start using the library. I think this was the only issue we were working through during our evaluation period before we purchase.

We will be more than happy to test out the solution once it’s available though. (or even before it’s available publicly if needed.)

#7

Would you mind trying

https://gojs.net/temp/go-module-2211b.js

In place of go-module.js and see if it fixes the issue (pre-workaround)?

#8

That DOES appear to have resolved the issue so that the work around is no longer needed!

#9

Thank you for the confirmation. This is a provisional 2.2.11 build, but the final 2.2.11 (the one that will be on npm, etc) isn’t finished yet, and will be out in a week or two. You can use this build or your workaround in the meantime, and I will reply to this topic again when 2.2.11 is released.