4 ms·
They key thing is that require(esm) shipped in node 22, and is being back ported to node 20. Since Node 18 maintenance ends in less than a month, this means al
by jauntywundrkind 2y ago
They key thing is that require(esm) shipped in node 22, and is being back ported to node 20.
Since Node 18 maintenance ends in less than a month, this means all Node versions will have good esm support, including for consuming esm-only libraries (which until recently did not work!)
This is noted somewhat in the article, but basically is the whole story to me. Its now possible to stop doing CJS libraries entirely. And with that, I don't see why we would do CJS at all.
- 3np 2y agoThere are still maintained and supported older versions of node.js by the likes of Debian, Ubuntu, Enterprise Linuxes. They backport security fixes and such during a longer extended window but are unlikely to port ESM-require support. It may not be relevant to you and obv nobody's obliging you to also support those users, just saying it's not that binary.
- mattmanser 2y agoIs that really "support those users"? If they need to use a new library version, they can install their own version of node instead of relying on the OS supplied one. All the OS version is doing is supplying the convenience of not having to install it. Or have I misunderstood how those versions of node are used?
- 3np 2y agoSometimes the entire reason why they are still on that older LTS dist is because they still need (e.g.) node 12 for some reason.
- mattmanser 2y agoThat really becomes a "not your problem" as a library author. If a user wants to use an old version of node, they'll have to use an old version of the library that still supports cjs.
- rafaelmn 2y agoIf you are pinning to unsupported node you should not expect new npm packages to work, ESM or not. However given my NPM experiences in the past, I would not be surprised that someone updated to ESM in a revision bump.
- forty 2y agoFunnily my conclusion was, on the contrary, that it's now possible to ignore ESM entirely when using/targeting nodejs ;)
- forty 2y ago(sadly at work, at this point we already have done the useless work of migrateming to ESM for no good reason other than having libs that were ESM only)
- 9dev 2y agoESM has heaps of benefits: being able to do static analysis, or limiting the exposed modules in a package, for example.
- selfmodruntime 2y agoTree-shaking also.
- jampekka 2y agoStatic analysis and tree shaking have been done with CJS for about a decade. https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7dfcad3 https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7d...
- wffurr 2y agoIn a limited way due to side effects from the require function. Reading that rant, the author did not seem to take much time to understand the rationale behind ES modules: “ yet for some completely unclear reason, ESM proponents decided to remove that property” is just pure ignorance.
- jampekka 2y ago> In a limited way due to side effects from the require function. In a limited way that covers something like 99.9% of CJS usage. Bundling is based on static analysis. If by side effects you mean running code, not just declaring exports, ES6 import does these side effects too. Thinking that CJS can't be used for static analysis or tree-shaking is the widest spread pure ignorance.
- moltar 2y agoAnnoyingly you have to use an experimental flag. That just adds too much friction. Latest Node version added Node options as config feature. I wish that was ported to every version of Node. Otherwise you have to set NODE_OPTIONS which can often be overwritten by some scripts in the execution chain.
- uasi 2y agorequire(esm) is no longer behind a flag in v22.12.0+ and v20.19.0+.