Open stof opened 2 months ago
I'm 100% of favor of migrating Encore to ESM, it's something I've also thought recently.
Shipping Encore as a CommonJS module means that we cannot upgrade our dependencies to versions that have migrated to ESM (as
Encore.getConfig()
is a synchronous API, any solution requiring an async context is a no-go).
Yeah, especially with #985 which forced us to introduce rpc-sync
dependency to make ESLint API sync, and here in #1303 where I couldn't upgrade to an ESM version (and #1313 aswell).
Also, do we want to write JavaScript ESM compatible code, or do we want to add an additional build step like... TypeScript?
More and more npm packages are shipping as ESM. In node, the compatibility between ESM and CommonJS has some limitation:
await import(...)
(but this can only be used in an async context)Shipping Encore as a CommonJS module means that we cannot upgrade our dependencies to versions that have migrated to ESM (as
Encore.getConfig()
is a synchronous API, any solution requiring an async context is a no-go).Migrating to ESM needs to be done in a new major version as it is a BC break for downstream projects. This will require writing the
webpack.config.js
file in ESM, either by usingtype=module
in the package.json or by usingwebpack.config.mjs
instead (which is supported by webpack)