When is ESM support planned?

[AmbitionsXXXV]

Pre-flight checklist

• I have read the contribution documentation for this project.
• I agree to follow the code of conduct that this project uses.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem description

When I wanted to migrate to ESM according to the latest version of electron-store, I found that forge.config.ts did not support ESM.

Proposed solution

Support ESM in forge.config

Alternatives considered

1. Wait for official support in future electron-forge versions.
2. Use a custom build process outside of electron-forge to support ESM.
3. Revert to CommonJS modules for the time being

Additional information

ESM support is crucial for our project as we aim to use modern JavaScript features and improve code maintainability. The ability to use 'import' statements directly would significantly simplify our development process and allow us to better align with current JavaScript best practices. We've already migrated most of our codebase to use ESM syntax, and electron-forge's lack of support is the main blocker for our complete transition

[SpacingBat3]

There's already a support for ESM, although you might need to use forge.config.mts for now, since Forge relies on other software in order to load some config formats based on their extension.
As of loading ESM directly in forge, which is mostly useful for extensions that Forge loads directly on its own, I've made a PR that is mostly finished and needs the upstream action in order to proceed with either merge of this or some opinions what I could still change: #3582.

[SpacingBat3]

As a dev that actually made a maker for forge with the use of ESM syntax and a requirement of using ESM to load it, I've also made an example how to apply this to Forge at its current stage. Having better implementation on Forge side would still be better suited for more transparent loading of stuff, so users of Forge toolkit don't have to care about whenever Forge loads something as ESM or CJS, so supporting both feels like a way to go unless there will be some movement to decide on dropping CJS entirely at some point in JS…

[augustsaintfreytag]

According to the merge request, this has been incorporated into Electron main two weeks ago but I’m guessing it’s release pending?

This would be a really helpful addition as it would also solve/prevent deepkit/deepkit-framework#615, an issue with the Deepkit type compiler getting understandably thrown off by using a different module setting in tsconfig than what is actually expected to be in the output code.

For Electron apps, this seems particularly strange because — assuming we’re all writing ESM syntax — the chain is ESM → CJS → ESM for everything running on an Electron renderer thread.

[smallsung]

As a dev that actually made a maker for forge with the use of ESM syntax and a requirement of using ESM to load it, I've also made an example how to apply this to Forge at its current stage. Having better implementation on Forge side would still be better suited for more transparent loading of stuff, so users of Forge toolkit don't have to care about whenever Forge loads something as ESM or CJS, so supporting both feels like a way to go unless there will be some movement to decide on dropping CJS entirely at some point in JS…

这个例子中，没在package.json中配置相对路径，最终使用的不是forgeConfig.mts，而是{}

[sebbean]

the chain is ESM → CJS → ESM for everything running on an Electron renderer thread.

this is really throwing me off on a brand new vite-typescript template build

wondering if that CJS in between is necessary

I've gotten a bit closer using this config override: