Unflagging Type Stripping in Node.js v22

[marco-ippolito]

I created this issue to track breakages that prevent unflagging type stripping in Node.js v22.
In October Node.js v22 will transition to maintainance so it means it will not be possible to backport.
Since type stripping is already enabled in Node.js v24, these libraries are not compatible with it and they eventually need to fix this issue.

The breaking change stems from libraries assuming the internal require.extensions['.ts'] is registered by ts-node while in Node >23 is registered by Type Stripping.

• 🐛 Bug: Node.js v23 testing with .ts files mochajs/mocha#5314
• webpack.config.ts is not compatible with Node.js v24 webpack/webpack.js.org#7629
• Rechoir is incompatible with Node.js v24 gulpjs/rechoir#49
• [BUG] Don't rely on require.extentions node-config/node-config#787

Let's try to track all the libraries affect and try to fix them before Node.js v22 goes maintainance.

(If you know a library that breaks drop a comment) @nodejs/typescript

[joyeecheung]

The breaking change stems from libraries assuming the internal require.extensions['.ts'] is registered by ts-node while in Node >23 is registered by Type Stripping.

Is that the only relevant breakage? AFAIR you don't actually need to insert require.extensions['.ts'] to support it, you can just catch it in the .js handler which, according to the funny algorithm we use to decide which handler to use, will be used as a fallback to handle .ts if there's none that's already registered by the users. I did that for .mjs but I left .ts etc. as-is because I don't know whether TypeScript support really needed it nodejs/node#55590

[joyeecheung]

Or if you want to see how I did it for just .mjs without interfering with .ts paths, see the commit adapted for v20.x joyeecheung/node@1c3f307

EDIT: actually now I realized that this commit has gone missing in the v20.x backport - although I think the breakage is less significant with .mjs because the biggest user of it (the esm package) had been broken on v18.x for other reasons a long time ago. We might still want to backport it to v20.x at some point even though I haven't seen anyone complained.

[ljharb]

It would be very unfortunate if Object.keys(require.extensions) didn't map to the exact list of known requireable extensions, though.

[joyeecheung]

I think they haven't been consistent for many years (.cjs has not been in the map, maybe never? That was how I found out about this funny algorithm in the first place)

[marco-ippolito]

If we agree to remove '.ts' from require.extensions that would fix the breaking change. Although it would make it inconsistent and should probably be removed as an api. If that's ok I can open a PR

[ljharb]

A lot of tooling, lots of which can't ever be updated, will break if require.extensions is ever removed, so i'm not sure that'll ever happen.

[marco-ippolito]

This PR should fix all these issues except mocha: nodejs/node#58657