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

141–150 of 152 posts

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

#141

Post by desmap »

fireattack wrote: post #140
desmap wrote: post #61

Earlier quoted context omitted.

But how do you solve it in a tsc context? Using the default prop doesn't work in tsc and breaks all type information because tsc just doesn't know of any default prop.

Not exactly sure what you mean but you can check this: https://github.com/microsoft/TypeScript/issues/2719

Thanks for the link. I meant following case:

A TS file which compiles to an es6 ("esnext") module cannot import cjs. Either node breaks or TS' type-checking fails. Former if you omit default when importing and latter if you introduce .default in the TS codebase.

It's a bit complicated, what I just wrote about is reflected in the chart in step 4-6 here https://github.com/microsoft/TypeScript/issues/18442#issueco...

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

#142

Post by [deleted] »

WorldMaker wrote: post #136
desmap wrote: post #43

fwiw, TypeScript and ES Modules are just not compatible and never will be: https://github.com/microsoft/TypeScript/issues/18442#issueco...

That chart shows that Typescript is incompatible with CJS modules, because it inherits ES Modules incompatibilities with CJS, not that it it is incompatible with ES Modules.

[deleted]

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

#143

Post by wildpeaks »

Androider wrote: post #137
wildpeaks wrote: post #92

Honestly, all I need is a standardized way to publish and consume packages directly as Typescript (right now you can point "main" & "types to it, but I'd rather something like export maps) because the transpilation should be done by the end user as you can't assume which build target they might prefer.

Typescript transpilation is already pretty slow when just used for your own application, if all the node_modules directory entries were in TS I'd probably be looking at hours for the transpilation.

I removed Babel from my toolchains a while ago (and instead use TS to transpile even dependencies), so the compilation times are fine.

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

#144

Post by WorldMaker »

jkrems wrote: post #139
WorldMaker wrote: post #131

Earlier quoted context omitted.

It is possible, but you have to hack the Node require() loader to do it, teach it a lot about ESM loading, and then hope the downstream CJS don't have timing bugs around "very long" synchronous require() loads. https://github.com/standard-things/esm

I'm not sure that's really relevant here because esm is just one of the transpilers for module syntax, it's not running native modules at all. The same can be achieved with the babel CLI or TSC etc. and the right configuration. But it's not really "ESM loading". It's compiling ESM to CJS and then running CJS. It's true that transpiling to CJS will continue to work, no matter what.

To my understanding this ESM module uses native ESM loading on Node versions that support it, which is why others point out its behavior with top-level await is deficient in the same ways that Node's own behavior is, though it tries.

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

#145

Post by z3t4 »

WorldMaker wrote: post #132
z3t4 wrote: post #129

Earlier quoted context omitted.

Sync xhr is being depricated. Meanwhile Google and Facebook analytics/tracking freeze the main thread for a whooping two seconds. Why not push the module dependencies with http2 push? The problem is not technical. Its big money wanting to break backwards compatibility.

Even HTTP/2 Push is an order of magnitude slower than local File I/O on a good day with perfect (internet) weather. ESM isn't even the first approach to try to deal with this, for instance AMD had nothing (at first) to do with "big money" and everything to do with average web developers trying their best to practically solve the module problem for the web and CommonJS was never going to be an option in a web browser…

The Node.js module system is only loosely based on CommonJS. The Node.js module system is probably the biggest reason of the success of the Node.js ecosystem. Ifyou want to attack Node.js you would start with the module system.

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

#146

Post by greggman3 »

smt88 wrote: post #33
greggman3 wrote: post #23

Earlier quoted context omitted.

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

aliases help you use bar from foo.bar and moo.bar. They don't help you with 2 files both of which declare foo.bar

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

#147

Post by greggman3 »

manigandham wrote: post #28
greggman3 wrote: post #23

Earlier quoted context omitted.

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.

in one file declare

    namespace foo {
      class Bar ...
    }
In another file declare

    namespace foo {
      class Bar ...
    }
Now use both foo.Bar from file 1 and foo.Bar from file 2 in the same project. Aliases don't help with this

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

#148

Post by manigandham »

greggman3 wrote: post #147
manigandham wrote: post #28

Earlier quoted context omitted.

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

in one file declare namespace foo { class Bar ... } In another file declare namespace foo { class Bar ... } Now use both foo.Bar from file 1 and foo.Bar from file 2 in the same project. Aliases don't help with this

Different assemblies with the same assembly name, namespace and class? Use an extern alias (which is how different versions of the same assembly can be used if necessary): https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

Different assemblies with different assembly names but same namespace and class? Just use the fully qualified type name (and alias it for a shorter name).

Single assembly/project and namespace with the same class in multiple files? If you're just spreading out the code then use partial classes, otherwise why would you define the same type twice?

C# (and other languages) that use virtual namespaces can do everything that file-based namespaces can do, but also support many more scenarios.

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

#149

Post by manigandham »

greggman3 wrote: post #146
smt88 wrote: post #33

Earlier quoted context omitted.

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

aliases help you use bar from foo.bar and moo.bar. They don't help you with 2 files both of which declare foo.bar

Why would you declare the same type in 2 different files in the same project?

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

#150

Post by jokethrowaway »

While I understand why it was done, I feel ESM vs CJS Will be the breaking point for node.js. All my clients are using Babel to avoid this single issue but it's slow enough to be a DX problem.

I wonder if deno (maybe with a tsc reimplementation written in rust) will take its place for new projects. Personally, I've already suffered enough with python 2/3 and decided, after 9 years writing node, to use uniquely rust for new backend development.

Frontend development is quite a slow process as well, but all the faster alternatives imply knowing a different language - which impacts developers availability (given historically frontend developers are mostly JS).

Post reply on HN