Closed NemoStein closed 1 year ago
Ok, I was a bit naive, I admit... Just changing the bundle type to esm is not enough for some reasons.
Firstly, neutralino injects the globals into "./resources/js/neutralino.js" If this file (even if empty) don't exist, no globals are set.
Other issue is that the modules app.ts
, extensions.ts
, init.ts
, updater.ts
, window.ts
and websockets.ts
tries to access the Neutralino
global object, instead of importing what is needed directly.
In a modular approach the Neutralino object don't exist.
I assume that simply changing this would be enough, but I could be terribly wrong:
// From
Neutralino.events.on('ready', async () => { /* ... */ })
// To
import * as events from '../browser/events';
events.on('ready', async () => { /* ... */ })
The module websockets.ts
is an example where the import is already there, but usage is mixed.
Note: the current generated .d.ts is not trustworthy in a ESM environment
Looks like there was no update on your pr, but i seriously still hope for this even a year after i made that issue (#26). I closed it as I got no response from the developer for a good few months and i thought that it was not planned. ESM is the future and we definitely should support as much as possible.
Yea, the PR is waiting for review/approval. I'm still hopeful...
ESM is the future and we definitely should support as much as possible.
I've been saying that the bundle era is getting to it's end.
The same way jQuery made DOM manipulation and Ajax (XMLHttpRequest) easy and sparked querySelector
and fetch
, budlers solved an issue that ESM made obsolete.
It's the only way forward, especially with importmaps getting traction in browsers.
Hey @NemoStein Thanks for this idea. Yeah, ESM support looks nice for the future. I've done a small change for your implementation via this commit
Now, we can use Neutralino APIs as follows:
<script type="module">
import { init, os } from './js/neutralino.mjs';
console.log(init);
init();
os.showMessageBox('Mm..', 'ESM');
</script>
However, we need to do something from the framework side too since it still uses neutralino.js
to find required globals (i.e., NL_PORT
). Perhaps, we can load only globals when we use neutralino.js?globalsOnly=true
. I will check and update the framework side via https://github.com/neutralinojs/neutralinojs/issues/1048 soon
Thanks :tada:
I don't know why https://github.com/neutralinojs/neutralino.js/issues/26 was marked as completed and closed, but the feature is actually valid and desired.
Importing the API is way more elegant than globals, have fewer vulnerabilities and are (arguably) easier to work with, especially in a bundler-free environment. E.g.:
Only a simple change in the build process is required for this to work: https://github.com/neutralinojs/neutralino.js/blob/d6884b796ff43bd1eec8909d7168a17bdba7b795/build.mjs#L58
Changing
iife
toesm
is enough to output an ES module and could be easily configurable.Furthermore, the
.d.ts
should come together with the.js
, allowing IDEs to deliver better typings.