51–60 of 152 posts
Wow, I've been coding JS/Typescript frontends for years and somehow completely missed out knowing anything about CJS & ESM or their differences. I guess it's all irrelevant when you don't use Node, aren't publishing libraries, and are compiling all JavaScript into bundles for deployment and never read the bundled code.
Holy crap, this redefines dependency hell.
It's always surprising to read about the trouble this causes for Node. I've been writing mostly Webpack-compiled JS for the past few years, and it seems to allow any random mixture of require and import. Have I just been avoiding trouble areas by chance?
And dynamic imports are still complicated sometimes
I’ll conclude with three guidelines for library authors to follow: Provide a CJS version of your library Provide a thin ESM wrapper for your CJS Add an exports map to your package.json This seems like the same fallacy of python’s 2to3, and why they should have written 3to2 instead. If ESM is the new way, library authors should instead have a CJS shim to prevent fossilization of cruft.
> This seems like the same fallacy of python’s 2to3, and why they should have written 3to2 instead. This is incredibly insightful. I'm frankly a bit stunned. I would never have thought of this (and clearly the Python people also didn't) but it is absolutely true. It's also a very transferable strategy for any time compatibility is to be broken. Is this an original thought of yours or do you have references to further…
It's always surprising to read about the trouble this causes for Node. I've been writing mostly Webpack-compiled JS for the past few years, and it seems to allow any random mixture of require and import. Have I just been avoiding trouble areas by chance?
There are high chances you are relying on some non-spec compliant behaviors but you don't know about it. For example, ESM exports have immutable bindings, which means, mocking exports for unit testing is impossible. If it works for you, it's because you transpile the code from ESM to CJS (either via `babel`, `rewire` or similar tool).
I’ll conclude with three guidelines for library authors to follow: Provide a CJS version of your library Provide a thin ESM wrapper for your CJS Add an exports map to your package.json This seems like the same fallacy of python’s 2to3, and why they should have written 3to2 instead. If ESM is the new way, library authors should instead have a CJS shim to prevent fossilization of cruft.
OP wrote, note that it’s easy to write an ESM wrapper for CJS libraries, but it’s not possible to write a CJS wrapper for ESM libraries.
Wow that was informative. So ES Modules is really about the Red functions [1] getting module support. I find it fascinating watching our understanding of async computation mature over the years. [1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
>async computation mature over the years
A good thing, really, but would be much better if the experience from few decades ago wasn't ignored by cool kids who mature.
Earlier quoted context omitted.
> Node does not always fully initialize the dependency module before returning from require(). Unsure what this means. The only reason this happens is because an unfinished copy is provided to the dependency that is causing a circular reference.
It means you can get a half-initialized module back from a require() call.
Another issue about module import I encountered before and wasted me 1 hour to find the culprit: When converting TypeScript that using `import default xxx` to JS using `tsc`, it would convert it to something like `exports.default = xxx`. To import it, you have to use `const XXX = require('./mo.js').default` instead of just `const XXX = require('./mo.js')` in plain ES6 JS. This is fine but Babel used to [1] be able to…