Repository navigation
Switch to ESM breaks 3rd party libraries #103
Description
Given the fact that long.js is used by 1m+, hard switch to ESM is ... well ... weird
Yes, those projects can pin version to 4.0, but that means that overall package updates (e.g. npm update --depth 1) to fix security vulnerabilities in less maintained projects breaks everything (which i've just experienced)
And asking 1m+ users to update their code is not realistic
Btw, official NodeJS roadmap places Stability as top-most priority:
Stability Policy
The most important consideration in every code change is the impact it will have, positive or negative, on the ecosystem (modules and applications).
Activity
pauldraper commentedon Oct 28, 2021
That's why it was a major version bump.
Because it has breaking behavior.
dcodeIO commentedon Oct 28, 2021
I can relate to the frustration surrounding ESM and am open to hear this argument out, though I have to admit that so far I cannot quite follow the reasoning in the OP.
vladmandic commentedon Oct 28, 2021
i agree its exactly how semver is supposed to work - major version bump for breaking change
for browsers, esm is definitely the way to go - no doubt
(also for
nodejstypescript projects as tsc will do resolving)however, i dont see a benefit of
esmfor off-the-shelfnodejsuser(yes,
amd/umdare old, but need a working alternative, not just deal-with-it)how to consume
esminnodejs?type=modulewhich is not always the casenodejsbelow 14 is what? and how many users are still onnodejs12?i have 1k users, not 1m and i still get those questions often
perhaps if
nodejsadopted import syntax as standard so we can get away from require completely, i'd be completely for it. butnodejsis what it is - and we're likely looking at distant future for thiswhat i do for my library is package both
esmandcjsversions (andiife, but thats another story)import * from ...resolves toesmversionconst x = require('..')resolves tocjsversionalso, rules are slightly different when library has small number of users vs +1m like this one has
how many people run
npm update --latest? i know i do. and every time i run into problems because of that, i fix it. but if onlyesmis packaged, there is no solution without modifying 3rd party libraries which is not an optiondcodeIO commentedon Oct 29, 2021
One challenge I am seeing btw. is where the CommonJS module just exports a single class, here
Long. What one basically wants for backwards-compatibility is to retainwith an upgrade path of
which isn't exactly compatible, also when it comes to typings. What's the typical attack angle there?
For instance, for the former, typings are
export = Longwhile for the latter it'sexport default Long.vladmandic commentedon Oct 29, 2021
yes, its a challenge, but:
cjsandesmat least gives user options and having justesmis bad fornodejsuserse.g. i could handle difference in import signature with packager preprocessing. not ideal, but workable.
cjstarget onlydcodeIO commentedon Oct 29, 2021
I might me overlooking something, but it seems that if the package is ESM first, then having a CJS re-export is off the table due to the lack of top-level await. Or is there a way?
For reference, here is what I have so far.
dcodeIO commentedon Oct 30, 2021
There is an UMD fallback now. Let me know if there are any issues :)
pauldraper commentedon Nov 1, 2021
Thanks! I agree the Node.js 12 support (EOL May 2022) is the compelling reason to add this; that's how I cam across this.