[HN Gopher] Require(esm) in Node.js
___________________________________________________________________
Require(esm) in Node.js
Author : tilt
Score : 16 points
Date : 2024-03-21 10:35 UTC (12 hours ago)
(HTM) web link (joyeecheung.github.io)
(TXT) w3m dump (joyeecheung.github.io)
| jauntywundrkind wrote:
| It's all just so extra crazy because https://github.com/standard-
| things/esm has just worked for so so long. The intense module
| discussions kept happening, about why it wouldn't work or how it
| would blow up, but standard-things/esm was already out & working
| great.
| lloydatkinson wrote:
| > Recently I landed experimental support for require()-ing
| synchronous ES modules in Node.js, a feature that has been long
| overdue.
|
| Oh come on, overdue for what purpose? Digging Node out of another
| Node created hole?
| dcgudeman wrote:
| Did you read the article? He explains the motivation for the
| change pretty clearly.
| WorldMaker wrote:
| The motivation seems to be "many people have transpilers
| configured wrong" and this seems an extreme solution to
| fixing people's transpiler configurations. Especially because
| it will still fail for modules using top-level await
| (anywhere in their dependency graph), so it is at best a
| band-aid. Beyond that it does seem to be missing real
| motivating use cases. What real reason in 2024 is there to
| use CommonJS at the top level in NPM? How hard is it to
| rewrite `require()` statements to `await import()` ones,
| especially when the fix is a transpiler configuration change
| away?
| pquki4 wrote:
| I don't know how much experience you have, but in the JS
| world there are band-aids everywhere. They "fix" a lot of
| real-world problems, help push things to production, and
| are more important than you think.
|
| Just look at the typing gymnastics in TypeScript.
| dimgl wrote:
| Appreciate this change. The ESM stuff is nightmarishly esoteric.
| Most recently I ran into ERR_REQUIRE_ESM while trying to write
| Playwright E2E tests that import from other packages in our
| monorepo.
|
| I really think the way ESM was handled hurt Node.js a lot. Couple
| this with the introduction of TypeScript and complexity in the
| Node.js ecosystem skyrocketed. I've lost so many hours on this.
|
| Thankfully libraries like esbuild exist (and by extension `tsx`
| which uses esbuild under the hood).
| https://github.com/privatenumber/tsx
| paulddraper wrote:
| > After dwelling on this a bit, I think the reason why the
| synchronicity of ESM didn't lead to a synchronous require(esm) in
| Node.js sooner was more cultural than technical. There seemed to
| be a silo problem between those who worked on the ESM
| implementation in Node.js/communication with the standard bodies
| and those who didn't.
|
| Must be something like that.
|
| This never made a lick of sense.
|
| (At the very least for synchronous modules.)
| sam_goody wrote:
| Awesome that this is in Node.
|
| I created require-esm-in-cjs[1] two years ago when I needed to
| require ESM modules in a commonJS (regular legacy) page.
|
| It is only a few bytes long and is simple - it effectively causes
| ESM modules to load synchronously by checking every 100ms if the
| JS has loaded before allowing the page to continue.
|
| I have been meaning to improve it, such as adding a timeout and
| whatnot but never got around to it (it is good enough for my
| needs) - but always thought it was odd that something so
| (relatively) simple to hack around and so low in the stack can
| not be supported natively.
|
| It gets a fair amount of downloads even though it doesn't get
| much visibility so I guess I am not the only one who felt the
| need. But native is MUCH better!
|
| [1]: https://www.npmjs.com/package/require-esm-in-cjs
___________________________________________________________________
(page generated 2024-03-21 23:02 UTC)