Node Modules at War: Why CommonJS and ES Modules Can’t Get Along • Hacker News Board

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

#21

Post by dfabulich » Thu, Aug 06, 2020, 6:39 AM UTC

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.

(Author here.)

You were not using native ESM in Node years ago. Node 14 shipped with unflagged ESM support just this year. (If I had to take a guess, you were probably transpiling "import" statements into "require" statements and/or bundles, which honestly works better than native ESM, because there's no interop issue.)

Almost all of the most depended on NPM packages are CJS, and provide no ESM exports. https://www.npmjs.com/browse/depended

lodash, react, chalk, commander, moment, express, axios, and vue are all CJS.

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

#22

Post by Doxin » Thu, Aug 06, 2020, 6:49 AM UTC

dimgl wrote: post #20

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.

It means you can get a half-initialized module back from a require() call.

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

#23

Post by greggman3 » Thu, Aug 06, 2020, 6:55 AM UTC

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 namespace then if you ever need to use those 2 projects together one of them will have to be re-factored.

That problem doesn't exist in modern JavaScript. There are no namespaces. There is just floating references to code.

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

#24

Post by aPoCoMiLogin » Thu, Aug 06, 2020, 6:55 AM UTC

You can use ESM (including dynamic import) in node 6+ (without babel) by using https://github.com/standard-things/esm and cut the `.mjs` and "it can't work like that" crap.

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

#25

Post by randomsearch » Thu, Aug 06, 2020, 6:55 AM UTC

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…

As a Java programmer dropped into JS land, I totally agree. Keep it simple, one way to achieve something wherever you can. Pythonic, in other words. What I don’t understand is why we didn’t learn from other major languages that had gotten this right already.

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

#26

Post by dbetteridge » Thu, Aug 06, 2020, 7:02 AM UTC

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…

1. Get the default export as x

2. Get the exported value x

3. Get all exported values and call the object x

4. Get the exported value x and call it y

They're all different because they allow you to do different things, and fairly readable.

Edit: Just realised dimgl said the same 45min ago, my bad!

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

#27

Post by onion2k » Thu, Aug 06, 2020, 7:05 AM UTC

Rollup makes building both CJS and ES versions of a library fairly straightforward. https://rollupjs.org/guide/en/#outputformat

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

#28

Post by manigandham » Thu, Aug 06, 2020, 7:07 AM UTC

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…

That’s not true. You can use aliases just fine. .NET is great with this.

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

#29

Post by mantap » Thu, Aug 06, 2020, 7:13 AM UTC

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.

I feel the opposite. ESM is a nightmare and I hope I can avoid using it in node as long as possible.

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

#30

Post by fireattack » Thu, Aug 06, 2020, 7:17 AM UTC

dbetteridge wrote: post #26

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…

1. Get the default export as x 2. Get the exported value x 3. Get all exported values and call the object x 4. Get the exported value x and call it y They're all different because they allow you to do different things, and fairly readable. Edit: Just realised dimgl said the same 45min ago, my bad!

I think people (like the author of this article) should explain the syntax of destructuring assignment {x} briefly to make it make more sense for the unfamiliar.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...