neutralinojs / neutralino.js

I don't know why #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.:

import { app, os } from 'neutralinojs'

Only a simple change in the build process is required for this to work:

neutralino.js/build.mjs

Line 58 in d6884b7

format : 'iife',

Changing iife to esm 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.

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 neutralinojs/neutralinojs#1048 soon

Thanks 🎉

Module version (ESM) of Neutralino.js