Support Node's ES Modules

[Jamesernator]

Important

Support for ES Modules in Electron will land in Electron 28 and will be available in the electron-nightly released on August 31st

🥳

Original Issue Below

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Feature Request

As of Node 13.3 ES modules have been unflagged (albeit still experimental), it would be nice to be able to use ES modules as supported in electron.

Currently when trying to run electron with an ES entry point (either .mjs or .js+"type": "module") electron fails to run.

For example:

> [email protected] start /home/jamesernator/Projects/electron-test
> electron .

App threw an error during load
/home/jamesernator/Projects/electron-test/main.js:1
import electron from 'electron';
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at Module._compile (internal/modules/cjs/loader.js:815:22)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:892:10)
    at Module.load (internal/modules/cjs/loader.js:735:32)
    at Module._load (internal/modules/cjs/loader.js:648:12)
    at Module._load (electron/js2c/asar.js:717:26)
    at Function.Module._load (electron/js2c/asar.js:717:26)
    at loadApplicationPackage (/home/jamesernator/Projects/electron-test/node_modules/electron/dist/resources/default_app.asar/main.js:109:16)
    at Object.<anonymous> (/home/jamesernator/Projects/electron-test/node_modules/electron/dist/resources/default_app.asar/main.js:155:9)
    at Module._compile (internal/modules/cjs/loader.js:880:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:892:10)

Alternatives Considered

This is primarily a request for support, the alternative is not supporting it but that would be unfortunate given ES modules will be officially supported in both browsers and Node but not usable by electron without additional tooling.

Additional Information

ES Modules are still new (and experimental) so actual implementation might be delayed (or put behind flag) however starting to consider implementation considerations now would be helpful for supporting this more readily in future.

[nornagon]

FWIW, Electron won't be supporting Node 13 as our policy is to only roll in LTS versions of Node. So, while we definitely want to support ESM, this isn't going to be happening until Node 14.

[pauliusuza]

Sure, following LTS makes sense for production releases, but there's no harm in creating a v10 branch and adding ESM support now with Node v13 which can be rolled over to v14 once it's out in April 2020.

[nornagon]

@pauliusuza "no harm" indeed, except that we would then have to make sure we backport every change from master into the v10 branch, which is a significant burden on the maintainer team.

We'll do like we've done for all previous release branches, and branch v10 once v9 is stable. See https://electronjs.org/docs/tutorial/electron-timelines.

[trusktr]

As a workaround, you can use the esm package for the time being. Just install it, import it, then any file you import after that can be an ES Module.

Then, once Node 14 is out and Electron upgrades, all you need to do is modify the entry point not to import esm, and to import your ES Module directly. All the rest of the code base will remain untouched.

[DalderupMaurice]

That got the job done, Thanks! @trusktr
I have a TS monorepo project for desktop and web and every possible combination of tsconfig resulted in one of both being broken. Adding ESM fixed the issue 👍

[awkj]

wish electron use deno replace node

[ghost]

@nornagon ES modules unflagged is expected to land in April for Node 12. For more details, see nodejs/modules#450.

[ghost]

As a workaround, you can use the esm package for the time being. Just install it, import it, then any file you import after that can be an ES Module.

Then, once Node 14 is out and Electron upgrades, all you need to do is modify the entry point not to import esm, and to import your ES Module directly. All the rest of the code base will remain untouched.

I don't quite undestand how you did this. Can you give an example of how this workaround is supposed to work?

Edit: nevermind, I got it working. My code looks like this now (if anyone's wondering):

./main.js:

require = require("esm")(module)
module.exports = require("./js/electronMain.js")

with my Electron (main process) startup code in ./js/electronMain.js

[kskalski]

Node 12.17 removed necessity to enable -experimental-modules flag, so I wonder if after incorporating #23789 it will just start working out of the box. And which electron release will get it... :)

[dy]

It is [email protected] already, with stabilized support for ESM. It is time for the ecosystem to gradually switch to common standard. Would be really nice if electron enabled modules. esm doesn't work with node@13+.

[nornagon]

As mentioned earlier in the thread, we will support this when Electron includes a version of node which supports it, and not before.

Electron only includes LTS releases of Node, and does not upgrade Node versions in stable releases. Node 14 won't be LTS until October, so the earliest version of Electron that could include Node 14 LTS is Electron 12.

[ghost]

@nornagon Node 12 LTS already supports it.

See the Node release notes:
https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V12.md#ecmascript-modules-----experimental-modules-flag-removal

[nornagon]

Ah, in that case Electron 11 will likely include support for it.

[ghost]

@nornagon I would expect some stuff to break without deeper testing of native ESM with Electron's API. Will the entire Electron API be supported or parts of it in ESM in Electron 11?

[MarshallOfSound]

Full transparency we might turn off node's ESM loader in Electron 11 and it will almost certainly be disabled completely in renderer processes. Still reviewing exactly what the implications of this loader, it's implementation and it's interactions with Chromium exactly are and when we know more we'll share it but I want to set the expectations quite clearly here. This is not a simple flag or switch we can just turn on and move on with our lives, there are significant security, performance and compatibility concerns that we need to address here.

[ghost]

@MarshallOfSound @nornagon While I understand the challenge of integrating Node and Chromium on a periodic basis, integrating ESM into Electron will be a challenge in itself.

I believe the spirit of this current issue is to sort out these security, performance and compatibility issues before ESM lands. Maybe it is impossible to do beforehand.

Any ideas on how to proceed? How should this be tackled?

[pauliusuza]

and it will almost certainly be disabled completely in renderer processes

Frankly, that's exactly the opposite of what I expected to hear.

[cata-code]

@pauliusuza Weback already converts all your imports into one file, so you can write things like import { ipcRenderer } from 'electron' in your client site code and it works.

[cata-code]

Latest version of Electron 9.0.5 uses Node.js 12.14.1, so according to the docs https://nodejs.org/dist/v12.14.1/docs/api/esm.html the only way to use ESM modules is to pass the --experimental-modules flag. But electron won't allow this flag, so we are stuck.

According to https://nodejs.org/en/about/releases/ Node v14 will be LTS at the end of October
Also, according to Electron's timeline https://www.electronjs.org/docs/tutorial/electron-timelines , releasing a version every 3 months, Node v14 will be part of Electron 11 released at the end of November.

If we get ESM module in Electron before Christmas it would be a great deal, but we shouldn't hold our breaths until then.

[ghost]

@cata-code --experimental-modules has been removed in 12.17.0 (LTS). Even if this is true, Electron might disable this feature because of security, performance and compatibility issues.

If there is such a precedent, I'm not convinced native ESM would land with 14.0.0 in Electron. There is much work to verify everything beforehand and no plan that I'm aware of.

Please take note of the comment history in this issue.

[cata-code]

Ok, so instead of waiting for this feature, we can use imports in electron main files with the help of webpack.

This is how I set it up for my app, using webpack for both client side and electron main files

webpack.config.cjs

const path = require('path')
const CircularDependencyPlugin = require('circular-dependency-plugin')
const webpack = require('webpack')
const nodeExternals = require('webpack-node-externals')

module.exports = [
  {
    target: 'web',
    entry: './src/js/index.js',
    output: {
      filename: 'script.js',
      path: path.resolve(__dirname, 'app/js')
    },
    plugins: [
      new CircularDependencyPlugin(),
      new webpack.ExternalsPlugin('commonjs', [
        'electron'
      ])
    ]
  },
  {
    target: 'electron-main',
    entry: './src/electron/index.js',
    output: {
      filename: 'index.js',
      path: path.resolve(__dirname, 'app')
    },
    plugins: [
      new CircularDependencyPlugin()
    ],
    externals: [nodeExternals()]
  }
]

index.js

import { app, BrowserWindow, shell } from 'electron'
import contextMenu from 'electron-context-menu'

async function createWindow () {
 ...
}

Foo.js

import { ipcMain } from 'electron'

export default {
  foo () {
    ipcMain.handle('foo') ...
  }
}

[kskalski]

I was using solution mentioned by @leontepe for quite some time and it allows me to use esm modules and imports without problems by using "esm" node module and this little wrapper (main_esm.js) for entrypoint (main.js):

var _require = require("esm")(module);
_require('./main.js');

ironically at runtime Electron complains that using require in esm modules, which apparently it thinks this file is (sic!), isn't supported:

(node:19076) Warning: require() of ES modules is not supported.
require() of main_esm.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename main_esm.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from package.json.

Hope that whatever version of Electron that will be branched from current master (which already includes #23789 forcing support of esm in node AFAICT) will allow me to remove above little hack.

[cata-code]

@kskalski I had a look at the source code for the esm module and when I saw this https://github.com/standard-things/esm/tree/master/src I realized how heavy the hack is. Also this is run every time you start the app.

I rather use webpack and compile it once, and then the app is optimized every time you run it.

Besides you are most likely using webpack for the client side code. So when webpack is run, it builds both main and render/client files.

[frank-dspeed]

@kskalski that is total wrong no one should need to use webpack so the solution is to use npm module ESM and wait till they fixed #24971

[kirkouimet]

When Electron upgrades to using Node 14, would I be able to do this:

my-app/package.json
{ "type": "module" }

my-app/index.js
const path = await import('path');

And then run:
electron index.js?

Would I also be able to use Node's --experimental-loader option? Such as:
electron index.js --js-flags=--experimental-loader loader.js

Would love this. How can I help?

[slhck]

There's a rather popular project that uses TypeScript and WebPack to build Electron apps with, which uses ts-node to load the TypeScript sources at runtime. It breaks with Electron v28 due to the way ESM modules are handled: electron-react-boilerplate/electron-react-boilerplate#3568

Would anyone be able to provide support or guide towards a fix? The specific issue seems to be only with Node v18.19.0 or above, and Electron v28. ts-node has some issues with ESM (see TypeStrong/ts-node#1997), but using --import tsx also does not seem to work out of the box.

[GabenGar]

Well it doesn't "load" typescript sources at runtime, it resolves them in typescript, stores them somewhere and then redirects require() calls to them, most likely achieved by monkey-patching require(). Which is of course not possible in ESM since import is a keyword and not a symbol.
The solution is to explicitly have a ts -> js transformation step in your build pipeline and drop ts-node from runtime dependencies.

[KaKi87]

So, I'm trying Electron 30 with the following :

import { app, BrowserWindow } from 'electron';

await app.whenReady();

const mainWindow = new BrowserWindow({
    width: 800,
    height: 600
});

await mainWindow.loadURL('https://example.com');

The commands runs indefinitely but nothing happens 🤔

What am I missing ?

Thanks

[hyrious]

@KaKi87 You can not await whenReady() from top level, see #40719. You must use whenReady().then(...). :/

[KaKi87]

Indeed, thanks !

It would be nice to update the docs, especially the quick start, to include ESM.

[KaKi87]

So, preload doesn't support ESM even with the mjs extension as long as sandboxing is enabled ?

[hyrious]

@KaKi87 Yes, if you print a log from the sandboxed preload script, you will find that the script is wrapped in an IIFE like this:

(function(require, process, Buffer, global, setImmediate, clearImmediate, exports, module) {
  // preload.js contents
})

So it seems the preload script is always executed in IIFE format with sandboxing enabled.

[KaKi87]

Is static import support planned ?

Meanwhile, could the dynamic import function be added to these ?

[StreetStrider]

@KaKi87 from my experience, it is better to just bundle everything (with the exception of electron/ deps) into preload.