Repository navigation
Unflagging Type Stripping in Node.js v22 #37
Description
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
- fix: override Node's native TS formats privatenumber/tsx#733
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
Activity
[-]Unflagging Type Stripping in Node v22[/-][+]Unflagging Type Stripping in Node.js v22[/+]joyeecheung commentedon Jun 9, 2025
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.jshandler which, according to the funny algorithm we use to decide which handler to use, will be used as a fallback to handle.tsif there's none that's already registered by the users. I did that for.mjsbut I left.tsetc. as-is because I don't know whether TypeScript support really needed it nodejs/node#55590joyeecheung commentedon Jun 9, 2025
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 commentedon Jun 9, 2025
It would be very unfortunate if
Object.keys(require.extensions)didn't map to the exact list of known requireable extensions, though.joyeecheung commentedon Jun 9, 2025
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 commentedon Jun 9, 2025
If we agree to remove '.ts' from
require.extensionsthat 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 PRljharb commentedon Jun 9, 2025
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 commentedon Jun 10, 2025
This PR should fix all these issues except mocha: nodejs/node#58657
module: refactor commonjs typescript loader
module: refactor commonjs typescript loader
marco-ippolito commentedon Jun 25, 2025
I tested against all the projects I found to be broken and v24.3.0 fixes them. I think it's safe to backport now
arthur-fontaine commentedon Jul 11, 2025
marco-ippolito commentedon Jul 11, 2025
This is not a typescript related problem, as it happens in .js files too, but it works if you use
.mjsor.mtsextension. Its a esm detection problem, please open an issue on nodejs/nodearthur-fontaine commentedon Jul 11, 2025
Oh sorry, you’re right. I didn’t test it with JS because I assumed it was valid syntax and that Node would handle it properly. I’ve hidden my comment. Thank you!
module: refactor commonjs typescript loader
alexsch01 commentedon Jul 16, 2025
Made https://github.com/alexsch01/tsnode as a wrapper with typechecking for nodejs 24.3.0+ for now
When it is unflagged for v22, I'll consider adding support for it in my tool
(definitely will add support if/when the experimental warning is removed for v22)
marco-ippolito commentedon Aug 1, 2025
Type stripping has been unflagged in v22.18.0 nodejs/node#59256. I'm gonna leave this issue open for a few days then we can consider it done unless have to revert it
marco-ippolito commentedon Oct 6, 2025
I'm gonna close this as it has been unflagged for quite some time now