Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

redfin.engineering

Post reply on HN
Print view View original

31–40 of 152 posts

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#31

Post by ThePadawan »

pjmlp wrote: post #13
iso8859-1 wrote: post #8

Enough with the hornet hate. They are great animals. If you know German, you can learn how great they are in the knowledge podcast of the Bavarian Broadcast: https://www.br.de/mediathek/podcast/radiowissen/die-wespe-un... Or if you prefer this Hessian article: https://www.faz.net/podcasts/wie-erklaere-ich-s-meinem-kind/...

They might be great animals, but as you know here trying to have a picnick with them arriving as an uninvited gang doesn't turn out a great outdoors experience.

I can't say I have ever been bothered by hornets as opposed to wasps.

(Central Europe)

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#32

Post by fireattack »

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 convert `const XXX = require('./mo.js')` to valid code, which made lots of people wrote it (incorrectly) that way (I was very baffled why people wrote like that since it does not work in plain ES6).

[1] https://github.com/babel/babel/issues/2212

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#33

Post by smt88 »

greggman3 wrote: post #23
fn1 wrote: post #10

JavaScript just gives to much options. I keep having problems with libraries because ES6 allows import x from "library"; import {x} from "library"; import * as x from "library"; import {x as y} from "library"; Just to compare Java uses this: import java.lang.Double; import java.lang.*; No renaming, not a gazillion options during in- and export, but one statement. If you want to rename something, assign it to a variab…

Java's packaging system sucks as does all the similar ones like C#, C++ etc compared to JavaScript's IMO. All of those the space of namespaces is global. You can't have 2 modules named math.quaterinions in any of those languages. You can in JavaScript. To put it another way, in order to prevent name clashes in C++/C#/Java you have to know the name of every other project on the planet. If someone uses the same namespa…

I honestly have no idea where you got the idea that namespace conflicts are a problem in C# or Java. Both have solved this problem (C# with aliasing and Java with packages).

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#34

Post by dsun179 »

foreigner wrote: post #12

The description of how require() works is not quite correct. Node does not always fully initialize the dependency module before returning from require(). It can't work that way, because Node allows circular require() dependencies. Try it!

The reason is not correct. Nodejs cache the require lot and so circular dependencies can work without returning half finished loads.

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#35

Post by e12e »

Meanwhile, I found this on how Deno handles modules (it's all esm):

https://www.sitepoint.com/deno-module-system-a-beginners-gui...

Note that - if you can get an esm out of your cjs - and it doesn't use any nodejs apis unsupported by deno, then you might be able to use it:

> (...) Several CDNs can convert npm/CommonJS packages to ES2015 module URLs, including: Skypack.dev, jspm.org, unpkg.com (add a ?module querystring to a URL)

Ed: submitted as: https://news.ycombinator.com/item?id=24069037 since I couldn't find an earlier submission, and maybe it'll generate some interesting discussion on deno / modern js vs node.

In particular I wonder if it'll in practice be easier to share (more) code between backend and front-end.

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#36

Post by maple3142 »

I think CJS can export 1 more thing than ESM is a problem too.

    // cjs.js
    module.exports = (a, b) => a + b
    exports.default = 'default'
    exports.nice = 69
    // esm.js
    import * as mod from './cjs'
    // what is `mod` now?
In babel, `mod` will be `{ default: [Function], nice: 69 }`, and the string 'default' will be discarded because ESM always exports a `{ [key: string]: any }` while CJS can export whatevey they want (`any`).

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#37

Post by rjeli »

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.

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#38

Post by 1337shadow »

rjeli wrote: post #37

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.

2to3 was still useful because all code was in python 2 when python 3 first came out.

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#39

Post by e12e »

e12e wrote: post #35

Meanwhile, I found this on how Deno handles modules (it's all esm): https://www.sitepoint.com/deno-module-system-a-beginners-gui... Note that - if you can get an esm out of your cjs - and it doesn't use any nodejs apis unsupported by deno, then you might be able to use it: > (...) Several CDNs can convert npm/CommonJS packages to ES2015 module URLs, including: Skypack.dev, jspm.org, unpkg.com (add a ?module querystri…

There's also a crutch - I'm not sure how attractive it would be in a project using deno, though. Maybe to get up and running quickly on deno when moving a legacy project from nodejs?

https://deno.land/std@0.63.0/node#commonjs-module-loading

Re: Node Modules at War: Why CommonJS and ES Modules Can’t Get Along

#40

Post by secondcoming »

tlarkworthy wrote: post #3

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...

The whole point of that article is that it hasn't really matured at all
Post reply on HN