Should vanilla-jsoneditor export UMD or CommonJS format?

[cloydlau]

For now svelte-jsoneditor & vanilla-jsoneditor export ESM only. For details see #195.

[josdejong]

Yes indeed, in short:

• Let's not export UMD as long as there are workarounds to get the ESM version working in older setups.
• Let's reconsider when there are real world cases that really can't do without a UMD/CommonJS bundle.

[cloydlau]

I think there is a misunderstanding.
It's not controversial that CommonJS was retired after the official standard ECMAScript module came out.
*.mjs is replacing *.cjs, that's correct.
But the birth of <script type="module"> doesn't mean the default <script> is deprecated, and probably never will.
I believe it's not at least primarily for compatibility reason. The type attribute has many values, not merely module.
I doubt how many websites are using <script type="module"> in production. I believe <script> is still mainstream.

[josdejong]

Yeah, it could be that there are people limited to using only the plain old <script> and exposing global variables like window.JSONEditor. If so, please drop a message here and explain your use case.

I think in general it will be possible in those cases to do something like:

<script type="module">
  import { JSONEditor } from 'vanilla-jsoneditor' // replace the package name with the real path to the bundle, or use an importmap
  window.JSONEditor = JSONEditor
</script>

and use the window.JSONEditor global from there.

And alternatively, you can probably create a bundle of your app yourself using webpack/browserify/rollup like discussed in #165.

[cloydlau]

<script type="importmap">
  {
    "imports": {
      "vanilla-jsoneditor": "https://unpkg.com/vanilla-jsoneditor"
    }
  }
</script>
<script type="module">
  import { JSONEditor } from 'vanilla-jsoneditor'
  window.JSONEditor = JSONEditor
</script>
<script>
  console.log(window.JSONEditor) // undefined
  setTimeout(() => {
    console.log(window.JSONEditor) // ok
  }, 1000)
</script>

Actually we can't access window.JSONEditor provided by <script type="module"> in default script tag because the execution of Module Scripts will be deferred.
Like I said before:

If one dependency is ES format, it compels other dependencies to use the same way (native ES modules), which makes it quite messy, see https://github.com/cloydlau/json-editor-vue#cdn--esm-2.

If this is true:

I doubt how many websites are using <script type="module"> in production. I believe <script> is still mainstream.

User will have to do a refactor in order to use vanilla-jsoneditor.
So create a UMD bundle of their app themselves' should likely be their only choice in real world.

[josdejong]

o wow, I didn't know that module scripts are deferred, you're right.

I actually have no idea if this is still a mainstream way of programming, via <script> and exposing libraries globally on window. It is not a pattern that I would like to promote, I think the new <script type="module"> and import is preferable (then you can't for example have the issue of scripts loading in the wrong order in the first place 😉). But again, if there is someone actually hitting the wall on this please drop a message here.

Though it's a bit ugly, there are still ways to solve this, for example:

<script>
  function onImportJSONEditor(JSONEditor) {
    // load the editor
  }
</script>
<script type="module">
  import { JSONEditor } from 'vanilla-jsoneditor'
  onImportJSONEditor(JSONEditor)
</script>

[kczx3]

Yeah, I am seeing this new version and investigating migrating from the older jsoneditor (not svelte or vanilla). We don't bundle any of our JS assets so would have to make use of this "hack" or bundle it as UMD myself apparently. Bummer.

[josdejong]

Thanks for your feedback @kczx3. So does this workaround work for your case?

[B1anky]

I have a use-case where an older version of Qt's WebEngineView only supports ES6 modules or lower and the current bundling requires I do some conversions to an iife format to get it to work properly. Is there any chance we could bring this back for legacy use-cases? I'm only using the vanilla-jsoneditor for my purposes though.

[josdejong]

Thanks for sharing your case @B1anky!

I did look into whether QT supports ES modules (ECMAScript modules), and I found the following documentation which explains that files with the *.mjs extension are supported and treated as ES modules. If that is the case, renaming the index.js bundle of vanilla-jsoneditor to index.mjs should make it work in QT. Is that something you can try out?

https://doc.qt.io/qt-5/qtqml-javascript-imports.html#importing-a-javascript-resource-from-another-javascript-resource

[B1anky]

We're using an older engine of WebEngineView (1.8) and it doesn't support it with an indication that the MIME type couldn't be resolved. We're relying on a really old Chromium version: 69.0.3497.113. As of right now we have to use rollup to target an ES6 version and manually use UTF-8 encoding in our .html file to get it working as of right now.

Attempting to use *.mjs unfortunately was investigated and does not work in our environment use-case, as much as we'd like it to. We're also not in a position to upgrade our Qt version.

[josdejong]

Ouch! Being stuck on a 4.5 year old browser and an old version of QT doesn't sound healthy 😅 (also not from a security point of view).

Good to hear you do have a workaround. If there is enough need for it I'll consider adding an UMD export.

[B1anky]

Yeah, tell me about it 😓. I requested we bump our version up, but it's not up to me unfortunately. The workaround isn't too much of a pain, just a minor nuisance. We're bundling the solutions locally, so at least it's not directly connected to the internet via import statements anywhere.