i mean that for basically every single package that started CJS and transitioned to ESM-only, the ESM versions have a tiny fraction of the total downloads of that package.
iow, a package going ESM only isn’t what matters - people consuming it is.
Yeah, in the end, only what people are installing matters. That's why I am building the inspector for people to see better what they are consuming, Which might hopefully give a bit more incentive to move.
sure. but “look how many packages have gone ESM only!” Isn’t a reason to move when the actual data shows that doing that will tank adoption for your package.
On @fast-check.dev side I'm waiting for require-ESM to be backported into Node 20 before dropping the dual mode (or Node 20 not to be supported anymore). It will be so great to drop this code 😍
hopeful this will be the case, but it isn't clear we'll get require(esm) backported to Node 20, no? Or there has been good progress lately? Joyee was doing a ton to try to make this one happen
Node 18 EOL is at the end of April, Node 20 EOL is a year after that. Joyee was trying to port require(esm) to Node 20 though but it is a dominoes of never ending commits to be backported it seems
If I'm narrowing down the problem space, the fundamental problem is "ESM cannot be easily instrumented at run time due to the exterior immutability of modules". It's of course an APM problem, but also anything else that needs to mutate modules at run time. And, arguably, it's a feature, not a bug.
I've been waiting for that for a while. Shipping dual is exhausting for what we do: monorepo that uses ESM in local dev, but has to ship UMD for our core platfform.
But type: module still breaks our main app (which has some debt indeed…).
I’ve been publishing ESM-only since 2021 as well and I strongly support any effort to ditch CJS. Unfortunately people still use legacy tools that don’t support ESM. If a CJS package `require()`s ESM, it’ll still break in Jest, Webpack 4, and other tooling.
If you test code that will be bundled anyways, you have a ton of dual-package hazard to fight in Vitest that will never happen with the final bundled version (or even in native node).
=> staying away from vitest with every package combo that could cause a dual-package hazard, which means in almost all projects where the ecosystem has been around for a while.
For me, it's either jest or node-test - vitests module resolution can get very weird.
With require() support in Node.js its important to avoid top-level awaits in ESM – can be good to note when advocating moving to ESM – in libraries, stay away from top level awaits
I agree and it’s a bummer, top-level awaits are great! Made my web config packages so much more streamlined, but came with some hairy dependency management issues
Comments
The SemVer/Epoch, now this one. Keep them coming 🤍
and yes, ESM ftw!!
Ever considered that?
Seems less costly and more straight forward.
or implement a module to enable `await npm.install(name)` in your app before loading modules via require.
there are so many ways.
ESM essentially forces you into their ways & downsides
Counted properly, i suspect the number is much much smaller.
iow, a package going ESM only isn’t what matters - people consuming it is.
On @fast-check.dev side I'm waiting for require-ESM to be backported into Node 20 before dropping the dual mode (or Node 20 not to be supported anymore). It will be so great to drop this code 😍
I also wrote one about CJS and ESM
https://medium.com/@jolodev/oh-commonjs-why-are-you-mesming-with-6fb12a84bd77
https://bsky.app/profile/phry.dev/post/3lhil3pbirc2j
It's criminal that lambda/server less has convinced people that bundled server code is a good thing.
i'm for shipping dual until node.js versions that don't support `require(esm)` reach eol.
I'm seriously considering moving to ESM only too.
Maintaining CJS and ESM support for same package has not been a fun experience.
But type: module still breaks our main app (which has some debt indeed…).
For me, it's either jest or node-test - vitests module resolution can get very weird.