[d357r0y3r]

What's the story with supporting CommonJS libraries? I've tried to update many projects to ESM multiple times over the years, and every time, I ended up backing out because it turned out that there was some important upstream library that was still CommonJS - or even if we fixed those issues, our downstream NPM consumers wouldn't be able to consume EJS. So then you have to go down this rabbit hole of dual compilation, which actually means using something other than tsc.

[ItsHarper]

It's possible, but it can be weird and difficult: https://nodejs.org/docs/latest-v17.x/api/esm.html#esm_common...

Thankfully, actively-maintained CommonJS-only packages are quite rare by this point (in my experience).

> our downstream NPM consumers wouldn't be able to consume EJS

Node.js 20.17 and later supports loading ESM using `require()`: https://nodejs.org/api/modules.html#loading-ecmascript-modul...

The next version of Babel (currently in beta) is even going ESM-only.

[miohtama]

It's almost like Python 2 to Python 3 upgrade. Took a decade but everyone is finally happy.

[WorldMaker]

With "type": "module" there's very few reasons to do dual compilation unless you have very conservative downstreams that hate promises and async/await, and even then there's mitigations now (sync `require()` of async ESM).

It's been a while since I've had a trouble importing an upstream CommonJS library. Often it is easy enough in the rare cases where upstream is particularly old/gnarly you can vendorize an ESM build with rollup or esbuild.

That said, CommonJS is also now a strong maintenance signal for me and if a library doesn't have recent ESM builds I start to wonder if it is at all well maintained and not just a pile of tech debt to avoid. JSR has started becoming my first place to search for a library I need, ahead of NPM, because of JSR's focus (and scoring systems) on ESM first and good Typescript types.