Whatever happens please never give into any misguided pushes to support commonjs/amd/umd or any of the other non-standardised disaster module formats that cause Node and npm etc to be so painful! It's only very recently that modern build tools are managing to overcome such poor foundations...
Asset References: https://github.com/tc39/proposal-asset-references Alternative module reflections (wasm imports): https://github.com/tc39/proposal-import-reflection
The main problem to me is this push to this ESM thing, which I don't know what it brings to me. I understand it's a frontend thing, so I'm not sure why nodejs end npm need to be impacted.
- It has language syntax for importing and exporting instead of relying on an implicit global.
- It is asynchronous, allowing for top level await.
- It is reliably statically analyzable.
- Because it is asynchronous, module asset loading can happen in parallel which can mean a significant startup speedup for larger projects.
- It is standardized, so it behaves the same across Node, Deno, the web, bundlers, linters, and other tooling.
You also forgot another super important point:
- It actually works. How many times have we all run into some weird error or stack trace because node/npm/babel/webpack/typescript/jest/regenerator-runtime/babel-core/quantum-flux-inverter tower of cards collapses when a commonjs module somehow leaks in from node_modules?
Admittedly the largest project I'm working on is mostly in TS now, and I probably get most of the benefits of the import syntax even if require is used under the hood (including linters, which I think worked even before we switched to typescript).