Repository navigation
node 22.18 breaks npm package because of experimental-strip-types enabled #59364
Description
Activity
@nodejs/typescript
What errors? What reproduces them?
Happening here too:
nvm use 22->22.18Then we just run our unit tests as usual, or in CI
Doesn't happen with
22.17.1Exception during run: Error [ERR_INTERNAL_ASSERTION]: Unexpected status of a module that is imported again after being required. Status = 0 This is caused by either a bug in Node.js or incorrect usage of Node.js internals. Please open an issue with this stack trace at https://github.com/nodejs/node/issues at Function.fail (node:internal/assert:17:9) at ModuleJobSync.run (node:internal/modules/esm/module_job:430:12) at onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:647:42) at async formattedImport (/Users/rlearney/git/veritable-cloudagent/node_modules/mocha/lib/nodejs/esm-utils.js:9:14) at async Object.requireModule [as requireOrImport] (/Users/rlearney/git/veritable-cloudagent/node_modules/mocha/lib/nodejs/esm-utils.js:97:28) at async exports.loadFilesAsync (/Users/rlearney/git/veritable-cloudagent/node_modules/mocha/lib/nodejs/esm-utils.js:123:20) at async singleRun (/Users/rlearney/git/veritable-cloudagent/node_modules/mocha/lib/cli/run-helpers.js:164:3) at async exports.handler (/Users/rlearney/git/veritable-cloudagent/node_modules/mocha/lib/cli/run.js:379:5) { code: 'ERR_INTERNAL_ASSERTION' }
NB fixed with
NODE_OPTIONS="--no-experimental-strip-types"in all ourpackage.jsonsReacted by Mateus Caruccio and Paul CReacted by Paul CWhat I saw was that suddenly
__dirnamewas not defined. We do not specify type in our package.json files, so the project should fallback to type commons.This worked up until nodejs version 22.17, after upgrading to version 22.18 it broke our ci tests.
Adding the no-experimental-stripe-types option fixed our issue in 22.18.
I my opinion, this change shouldn't have been added in an 22.x version as a new default setting, as it breaks stuff. It was mentioned in 23.x something though, which is fine.
(I don't have access to specific failing code right now, will investigate further tomorrow if needed)
Reacted by Zeping Bai, Jason Efstathiou and JoeyWe've also run into this issue while executing tests using
mocha --require ts-node/registerReacted by Robert M. Learney, Jeremy Forsythe, Bailey Pearson, Vadym Kurachevskyi, Ben Mewburn, Edoardo Luppi, Christoph Gysin and Paul CIt looks like mocha, ts-node related issue. Not sure how does they implement the loader
I'm on PTO, I can look into this next week. Please provide a repro (even something with mocha) I can look into it when I'm back unless someone wants to give it a try
Reacted by StevenYou can look at #59366 , launching withNODE_OPTIONS="--no-experimental-strip-types"flag sends Node back to the old loader path; that’s why it cures both the “unexpected feature enabled” problem and the TypeError: undefined.getStatus crash, but I believe these are 2 separate issues - same cause, different effects.edit: educated, they're not related
You can look at #59366 , launching with
NODE_OPTIONS="--no-experimental-strip-types"flag sends Node back to the old loader path; that’s why it cures both the “unexpected feature enabled” problem and the TypeError: undefined.getStatus crash, but I believe these are 2 separate issues - same cause, different effects.That doesnt seem related to type stripping though @joyeecheung ideas?
I'll see if I can make a minimal example with the error in tomorrow.
This issue is also in the latest 24.5.0, I was struggling for the last couple of weeks upgrading, the this issue with 22. 18 led me to the the --no-experimental flag, which also solves my other problems (this is one gigantius project, that is 7 years old, that I work on. So not always easy to do upgrades)
- changed the title
[-]node 22.18 suddenly ships with experimental-strip-types enabled[/-][+]node 22.18 breaks npm pakcage because of `experimental-strip-types` enabled[/+]on Aug 5, 2025 That doesnt seem related to type stripping though @joyeecheung ideas?
As explained in #59366 (comment) - it might have something to do with the interaction between esbuild-register and the
.jshandler changes in #58657 (or that it may not be enough to make it transparent enough for esbuild-register)Here's a minimal reproduction https://github.com/simhnna/node-type-strip-issue/actions/runs/16770150006/job/47483217195
And I just tried tsx which isn't affected. So it's something ts-node specific https://github.com/simhnna/node-type-strip-issue/actions/runs/16770273430/job/47483598751
53 remaining items
@alexsch01 iI assume there’s no suitable workaround in third party code?
Here is a reproducer. The same behavior occurs in 22.19. @joyeecheun naively this does seem more related to the loader stuff rather than actually related to the experimental-strip-types flag
- added 2 commits that reference this issue
on Sep 19, 2025 My team just wasted a bunch of time debugging this issue. LTS versions should not be including breaking changes like this. It's insane to flip an experimental flag on by default in an LTS version.
Reacted by Bryan Opfer, Issiah Deleon, Florent, Mark Wiemer, Mateus Caruccio, Matt Kantor, akoskobra, Yaroslav Sorellya, hschmid-wi, Utku Erdoğdu and 5 moreReacted by HoishinAs others mentioned, I encountered issues with node >= 22.18 in combination with mocha. Additionally, we're using the
ts-node/esmloader:$ mocha --require ts-node/esmSetting
NODE_OPTIONS=--no-experimental-strip-typesfixed some of the issues, but caused others. Here's a minimised example to reproduce a bug that was introduced in 22.18.0 when used with--no-experimental-strip-types:$ cat mocha-loader-bug.ts import { config } from './config.js'; it('test', () => { const deployment = config.getRequired<string>('deployment'); console.log('deployment:', deployment) })$ cat config.ts export const config = { getRequired: <T>(key: string): T => key as T, };with
--no-experimental-strip-types:$ NODE_OPTIONS='--loader=ts-node/esm --no-experimental-strip-types' npx mocha mocha-loader-bug.ts ... 1) test: ReferenceError: string is not defined at Context.<anonymous> (file://mocha-loader-bug.ts:4:41) at process.processImmediate (node:internal/timers:485:21)without
--no-experimental-strip-types:$ NODE_OPTIONS='--loader=ts-node/esm' npx mocha mocha-loader-bug.ts deployment: deployment ✔ test 1 passing (2ms)$ node --version v22.18.0 $ npx mocha --version 11.7.2 $ npx ts-node --version v10.9.2- added a commit that references this issue
on Dec 31, 2025 This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.- added a commit that references this issue
on May 19, 2026 - added a commit that references this issue
on May 23, 2026 This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 240 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
Version
v22.18.0
Platform
Subsystem
No response
What steps will reproduce the bug?
After updating to node22.18 we see issues with builds. Looking through the change notes, I see that it now has enabled an experimental feature, and we now to have to add --no-experimental... to the command line in order to run our code in nodejs.
How often does it reproduce? Is there a required condition?
consistently failure in our CI pipelines unless --no-experimental-strip-types is added to node cli
What is the expected behavior? Why is that the expected behavior?
minor releases should not add experimental features to an existing lts version
What do you see instead?
Failing builds using node 22.18 (working fine with node 22.17)
Additional information
No response