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

101–110 of 152 posts

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

#101

Post by nemothekid »

wruza wrote: post #58
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 last time I asked here why async-await is even a thing, when you can just introduce light/green threads, coroutines, you name it, everyone jumped that it is even better when you mark awaiting points explicitly. Now that it goes from a blog post of some popular language designer, seems no one gonna disagree. >async computation mature over the years A good thing, really, but would be much better if the experience f…

In regards to JS, any reasons for a sync await seems to be rationalization.

Node is built on V8, which is built for browsers. Browsers have a single threaded execution model that also hides an event loop that runs the entire tab.

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

#102

Post by desmap »

inquisitiveio wrote: post #100
desmap wrote: post #57

Earlier quoted context omitted.

> should instead have a CJS shim 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.

I'm pretty sure services like pika.dev/skypack.dev/jspm.io are trying to solve the CJS to ESM problem so you can use it directly in the browser (or deno). Last time I checked they seemed to lean into using rollup to take care of the translation under the covers.

That's not the point here. It's about that a thin CJS wrapper to an ESM module isn't possible but the way around is.

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

#103

Post by chrisweekly »

kqr wrote: post #84
masklinn wrote: post #63

Earlier quoted context omitted.

> Porting Python 2 code to Python 3 was never the problem. You're, frankly, high as a kite. As the author of one such port on a large codebase, porting Python 2 code to Python 3 was absolutely a problem. The issue with 2to3 is that it assumed you'd do the conversion as a one-shot and straight flip over with entirely separate codebases (or dropping Python 2 entirely) from there on, which is completely insane. What the…

Isn't "migrating progressively through cross-version codebases" exactly what a 3to2 compiler would allow you to do? You'd write new code (and incrementally port old code) to Python 3, and then when you build the project you'd compile the Python 3 code down to Python 2 before building the entire project as Python 2, including all dependencies. So for over a decade, you'd be writing Python 3 code but building a Python…

Amen. Babel gets a lot of things right (and arguably has a tougher job than a 3to2 compiler would, given the speed of change and the target breadth / problem surface area).

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

#104

Post by chrisweekly »

no_wizard wrote: post #97

I use the ESM dependency to load ESM modules as a CJS shim: https://www.npmjs.com/package/esm I highly recommend it. Really let’s you unify on ESM modules without much thought

How did this escape my attention till now? Thanks for the link! :)

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

#105

Post by wonderlg »

praestigiare wrote: post #70

npm install esm Then everything just works. Top level await and all.

Wait till you throw a package.json with "type": "module" in there.

Everything used to work until Node 12.15, then 12.16 started throwing when trying to require type:module packages with `require` (which is what `esm` does)

https://github.com/standard-things/esm/issues/868

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

#106

Post by masklinn »

kqr wrote: post #84
masklinn wrote: post #63

Earlier quoted context omitted.

> Porting Python 2 code to Python 3 was never the problem. You're, frankly, high as a kite. As the author of one such port on a large codebase, porting Python 2 code to Python 3 was absolutely a problem. The issue with 2to3 is that it assumed you'd do the conversion as a one-shot and straight flip over with entirely separate codebases (or dropping Python 2 entirely) from there on, which is completely insane. What the…

Isn't "migrating progressively through cross-version codebases" exactly what a 3to2 compiler would allow you to do? You'd write new code (and incrementally port old code) to Python 3, and then when you build the project you'd compile the Python 3 code down to Python 2 before building the entire project as Python 2, including all dependencies. So for over a decade, you'd be writing Python 3 code but building a Python…

> Isn't "migrating progressively through cross-version codebases" exactly what a 3to2 compiler would allow you to do?

No. You'd have to migrate everything to Python 3 at once, and then "maintain" two different and incompatible codebases, one generated from the other.

> A 3to2 tool would solve exactly the problems you're bringing up, with no intoxication needed!

It would half solve (at best) one of them.

> I don't see why 3to2 would not have worked. It's a compiler.

Unless your 3to2 would literally reimplement Python 3 in Python 2, it would be a translator / bridge. Which can't work due to the semantics difference between Python 2 and Python 3: not every change translates mechanically and reliably. If they did, 2to3 would have worked.

> Who cares if the Python 2 code it produced looked a little wonky,

The maintainer who has to debug, probably.

> as long as it was correct

Which it wouldn't be.

> This is also not something completely foreign and unheard of. This is exactly how I've been porting legacy JavaScript applications to a more modern ECMAScript approach: write new code in the modern way, compile it down to legacy code compatible with the existing legacy code, and then run that.

The "modern way" of javascript is additive, it's about adding new features to the language, some of which can be implemented in terms of the old one (and which you can thus "backport" through a compiler or extending the existing APIs).

You don't run into pieces of code which are syntactically identical but semantically divergent. Which you absolutely do in P2 v P3.

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

#107

Post by nightski »

desmap wrote: post #99
Macha wrote: post #81

Earlier quoted context omitted.

It's not possible to write a nice automated transparent one for arbitrary libraries because of top level await, but it's totally possible for the 95%.

Re your point OP also commented/quoted someone with “I don’t think designing a system with the blanket assumption that some feature just won’t get used is a viable path.”

Yea they are looking at the ecosystem as a whole. But if you are a library author you have the power to control these things.

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

#108

Post by masklinn »

chrisweekly wrote: post #103
kqr wrote: post #84

Earlier quoted context omitted.

Isn't "migrating progressively through cross-version codebases" exactly what a 3to2 compiler would allow you to do? You'd write new code (and incrementally port old code) to Python 3, and then when you build the project you'd compile the Python 3 code down to Python 2 before building the entire project as Python 2, including all dependencies. So for over a decade, you'd be writing Python 3 code but building a Python…

Amen. Babel gets a lot of things right (and arguably has a tougher job than a 3to2 compiler would, given the speed of change and the target breadth / problem surface area).

> arguably has a tougher job than a 3to2 compiler would

It doesn't. Not that its job is easy, but its job is to take constructs which are brand new and translate them to an older version of the language.

Of the same language.

It doesn't have to deal with the language or the APIs literally working differently when used the same way.

The Python version of Babel would be 3to3 compiler.

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

#109

Post by kevin_thibedeau »

kqr wrote: post #48
1337shadow wrote: post #38

Earlier quoted context omitted.

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

Sure, but maybe upgrading the existing Python 2 code wasn't the problem: the vast majority of the Python 2 code alive when Python 3 was released was probably scrapped by the time Python 2 was EOL'd . Over a decade is a very long time for a codebase to live. (Again, there are exceptions, but the vast majority of websites or data processing scripts or whatnot are significantly re-written or decommissioned in – pulling…

I made all my Py2 code forward compatible with 2to3. It was mostly a smooth process when you're using the future imports and know what landmines to avoid. It still required manual intervention at times with Unicode support and libraries that have breaking API changes between versions.

The end result is something that can be Py3 native whenever I want. 2to3 is the right tool for the job. There is no way to map all Py3 features back into Py2 so 3to2 would be a broken mess that only supported a subset of the language.

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

#110

Post by recursive »

beart wrote: post #94
Humphrey wrote: post #41

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.

Unless you are developing libraries which will be published to the nodejs ecosystem, you really don't need to worry about this. You pick one of these when you first create your app which is typically based on whatever framework or template you are starting from, and you just always stick with that.

Also, typescript can compile `import`s into `require()`s.
Post reply on HN