neutralino.js icon indicating copy to clipboard operation
neutralino.js copied to clipboard

Module version (ESM) of Neutralino.js

Open NemoStein opened this issue 1 year ago • 3 comments

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.:

import { app, os } from 'neutralinojs'

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 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.

NemoStein avatar Aug 11 '22 15:08 NemoStein

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

NemoStein avatar Aug 11 '22 17:08 NemoStein

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.

EpicGamer007 avatar Aug 27 '22 02:08 EpicGamer007

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.

NemoStein avatar Aug 27 '22 18:08 NemoStein