Time for the periodic "how are ESM-only modules on npm doing" update:
Looked at some arbitrarily selected popular sindresorhus modules (delay, p-event), and >90% of installs continues to be of (now at least 4 years old) CommonJS versions.
Yeah, I don't think this qualifies as a success for ESM.
@Byte ES Modules; an addition to the ECMAScript specification that was *supposed* to replace the widely-used CommonJS format (for rather shaky reasons), and has completely failed to do so because it turns out that incompatible core language changes are a bad idea and apparently nothing was learned from Python 2/3
@joepie91 Something I've noticed is that because most packaging tools allow you to transparently use CJS within ESM and export ESM back to CJS, there's very little (to absolutely no) incentive for existing projects to rewrite all of their imports and deal with the more nuanced consequences of the change.
@crumbcake That holds true for (bundled) browser code; but crucially, not in environments with native support for modules, like Node.js, as there is no build step there.
Leading to a situation where everything seems to be 'fine' to people who only do browser-side code, but constant breakage in server environments of the same modules... 🥴
@joepie91 Decided to dig into the build artifacts for my SvelteKit app at work and to my surprise the entire backend is using ESM, I honestly expected it to be getting transpiled to cjs, but I guess SK is a new enough framework that they adopted ESM during it's development.
I think that's generally what we're going to see over the next few years, existing projects and frameworks will retain CJS throughout their entire lifespan, while greenfield development will be primarily built with ESM and transpiled to CJS for backwards compatibility.
@crumbcake That matches what I've seen, though paired with a crucial other trend that makes this possible in the first place: a broader move towards monolithic frameworks that reinvent their own wheels.
It used to be that modules had a single well-specified purpose, and it did that well, and even frameworks were generally designed to be highly interoperable. This eliminated whole classes of issues like month-long framework upgrade chores, library architecture incompatibilities, and bugs in utility functions (because everyone used the same well-tested ones).
However, since Node.js ended up in the startup hype cycle, that has been changing, with increasingly many do-it-all frameworks appearing (because those are really easy to market - large feature lists!), that barely interact or interoperate with the ecosystem at all, instead having their own buggy homegrown implementations of existing tools inlined into their codebase.
That does mean those frameworks are unlikely to run into issues interoperating with the existing ecosystem of CommonJS modules and can therefore afford to do ESM, but for all the wrong reasons...
@joepie91 what’s ESM?