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

11–20 of 152 posts

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

#11

Post by IshKebab »

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…

You can also do `import x, {y} from ...`. Very confusing to learn.

I think they did it like that for compatibility with CommonJS.

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

#13

Post by pjmlp »

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.

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

#14

Post by [deleted] »

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

[deleted]

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

#15

Post by [deleted] »

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

[deleted]

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

#16

Post by dimgl »

draw_down wrote: post #5

I haven’t seen CommonJS modules for years now, only ES modules. Didn’t realize this was such an issue still. > You can’t require() ESM scripts That’s one way to put it! Another would be to say that you don’t have to. require() came about because we didn’t have the import keyword.

I guess you don't work on Node.js backends.

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

#17

Post by sroussey »

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…

The order of operations was different: the packages ecosystem came before the imports language construct. The location and the name of libraries are not correlated (PHP is closer to Java here, in the default case). Also, the idea of tree-shaking means you don’t want to import the whole thing (options 1 and 3) when you use something like webpack. Renaming let’s you use competing names. There are decades worth of history and libraries to accommodate.

Your last sentence is like a C dev asking a Java dev why they don’t just compile to x64 and be done with it. It comes across as flippant and will likely attract downvotes.

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

#18

Post by dimgl »

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 package system has its own problems, and all of those examples you gave are very straightforward.

1. Import the default export as the name `x`.

2. Import named export `x` as the name `x`.

3. Import all of the named exports under an object named `x`.

4. Import named export `x` as the name `y`.

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

#19

Post by colinr »

dfabulich wrote: post #6
spankalee wrote: post #4

In two-and-a-half months the last 5 stable releases on Node, the last 2 LTS releases of Node, and all current major browsers will support standard JS modules. It's time we all published standard JS modules and only standard JS modules to npm.

> the last 2 LTS releases of Node (Author here.) Node 14 supports ESM, but Node 12 only supports ESM behind the --experimental-modules flag, and its error handling for incorrectly importing CJS is not good. In 2020, I think it's a bit early to go ESM only, especially since it's straightforward for CJS libraries to support both CJS and ESM clients. (I document how to do this in the article.)

The experimental flag was recently removed in v12.17.0 (though the release notes still say ESM is an experimental feature)

https://github.com/nodejs/node/releases/tag/v12.17.0

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

#20

Post by dimgl »

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!

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

Post reply on HN