Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

TypeScript had years to prepare for ESM, but they did not. Same with Jest. ESM was developed in the open and anyone could participate, including the TypeScript team. You are talking like ESM just happened overnight. It had been in development for 10 years.

Node.js released initial ESM support [1] in Node.js 12.17 in May 2020, 2 years later (!), TypeScript finally added support for ESM [2].

Here's a straight forward guide on how to use TypeScript with ESM: https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3...

[1]: https://nodejs.org/en/blog/release/v12.17.0

[2]: https://devblogs.microsoft.com/typescript/announcing-typescr...



> ESM was developed in the open and anyone could participate, including the TypeScript team.

This point stings for me, personally, since _I_ was the TypeScript language dev _in_ this wg trying to make our concerns noted, because we certainly did participate. However the group largely deadlocked on shipping with ecosystem compatibility measures, and what you see in node today is the "minimal core" the group could "agree" on (or be bullied into by group politic - this was getting shipped weather we liked it or not, as the last holdouts). The group was dissolved shortly after shipping it, making said "minimal core" the whole thing (which was the stated goal of some engineers who have since ascended to node maintainer status and are now the primary module system maintainers), with the concerns about existing ecosystem interoperability brought up left almost completely unaddressed. It's been a massive "I told yo so" moment (since a concern with shipping the "minimal core" was that they would never be addressed), but it's not like that helps anyone.

Like this shipped, because _in theory_, it'd be a non-breaking from a library author perspective to get node's CJS to behave reasonably with ESM (...like it does in `bun`, or any one of the bundler-like environments available like `tsx` or `webpack` or `esbuild`), and _in theory_ they're open to a PR for a fix... I wish anyone who tries good luck in getting such a change merged.


Fwiw I appreciate your effort! That sounds really frustrating.

I agree the recent bun/tsx/esbuild (but bun especially) has shown the node CJS/ESM fiasco was a bit of an emperor-wearing-no-clothes moment, where I think us every-day JS programmers just trusted the node devs at their word, that CJS/ESM had to be this painful...

But now, seeing that it doesn't have to be that way, it's like wait a sec...the last ~5 years of pain could have been avoided with some more pragmatic choices? Oof.


> TypeScript had years to prepare for ESM, but they did not.

How did they not? This is confusing to me, as I’ve been authoring and emitting ESM in TS for quite a few years now.


Curious to see how this one decision plays out for nodejs IF -

- module authors increasingly adopt ESM

- TypeScript experience with Deno is butter smooth

- npm packages work with Deno

- performance characteristics are similar

- DX for beginners just works (compared to thousands of stale articles with `require('pkg')` and `npm install pkg@latest` for nodejs)


As someone who uses Jest and alternatively enjoys and is frustrated by it, this isn't all Jest's fault. Node is just now releasing fixes for [significant memory leaks](https://github.com/jestjs/jest/issues/11956#issuecomment-180...) around ESM support within the [VM APIs](https://nodejs.org/api/vm.html) that Jest depends on.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: