tsImport() fails with ERR_MODULE_NOT_FOUND on Node 24 when a CommonJS-context .ts file imports an ESM dependency

[ryanbonial]

Acknowledgements

• I read the documentation and searched existing issues to avoid duplicates
• I understand this is a bug tracker and anything other than a proven bug will be closed
• I understand this is a free project and relies on community contributions
• I read and understood the Contribution guide

Minimal reproduction URL

https://github.com/ryanbonial/tsx-pkg-utils-node24-repro

Problem & expected behavior (under 200 words)

What happened: tsImport() throws ERR_MODULE_NOT_FOUND on Node 24 when a CommonJS-context .ts file imports a dependency from an ESM package. Works on Node 22.

What I expected: Same behavior on Node 24 as Node 22 (load succeeds).

Matrix with tsx@4.22.3: Node 22.13.1 ✓, 22.18.0 ✓, 24.12.0 ✗, 24.15.0 ✗.

Stack trace:

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '.../esm-fixture/dist/index.js?namespace=1779473031813' imported from .../config/package.config.ts?namespace=1779473031813
    at finalizeResolution (node:internal/modules/esm/resolve:274:11)
    at moduleResolve (node:internal/modules/esm/resolve:864:10)
    at defaultResolve (node:internal/modules/esm/resolve:990:11)
    at #cachedDefaultResolve (node:internal/modules/esm/loader:718:20)
    at #resolveAndMaybeBlockOnLoaderThread (node:internal/modules/esm/loader:735:38)
    at nextStep (node:internal/modules/customization_hooks:189:26)
    at resolveBaseSync (.../tsx/dist/register-D_B8UL5H.mjs:2:8642)
    at resolveDirectorySync (.../tsx/dist/register-D_B8UL5H.mjs:2:9781)
    at resolveTsPathsSync (.../tsx/dist/register-D_B8UL5H.mjs:2:11014)
    at resolve2 (.../tsx/dist/register-D_B8UL5H.mjs:2:12901) {
  code: 'ERR_MODULE_NOT_FOUND',
  url: 'file:///.../esm-fixture/dist/index.js%3Fnamespace=1779473031813'
}

The repro mirrors @sanity/pkg-utils's loadConfig(): tsImport(pathToFileURL(configFile).toString(), import.meta.url) where configFile is a CJS-context package.config.ts doing import { defineConfig } from '@sanity/pkg-utils'.

Bugs are expected to be fixed by those affected by it

• I'm interested in working on this issue

Compensating engineering work will speed up resolution and support the project

• I'm willing to offer $10 for financial support

[MCCVT]

The same regression breaks node: builtin specifiers too, not only ESM-dependency URLs.

On Node 24, the ?tsx-namespace= cache-buster query leaks into pass-through builtin specifiers: a downstream import('node:crypto') resolves as node:crypto?tsx-namespace=<timestamp> and throws ENOENT … open '<cwd>/node:crypto?tsx-namespace=<timestamp>'.

Real-world repro: drizzle-kit's schema-diff (invoked through Payload's migrate:create) imports node:crypto and fails under tsx on Node 24 with that bogus path.

Bisected: 4.21.0 works; 4.21.1 → 4.22.4 all fail (Node 24 only; Node 22 unaffected, matching this issue). Pinning tsx to 4.21.0 is the current workaround.

Does the fix in #802 also cover node: builtin specifiers, or should the builtin case be tracked separately?

[ryanbonial]

Does the fix in #802 also cover node: builtin specifiers, or should the builtin case be tracked separately?

Track it separately. #802 is scoped to file: URLs: it strips the percent-encoded ?namespace= artifact that the CJS bridge leaves inside a file URL's pathname before it reaches Node's default resolver. It never rewrites node: (or data:) specifiers.

The ENOENT ... 'node:crypto?tsx-namespace=...' failure has a different mechanism: the load hook (getFileLoadContext in src/esm/hook/load.ts) forwards non-file: URLs to nextLoad unchanged, so a node:*?tsx-namespace=<id> URL reaches Node's default loader, which treats it as a literal path and calls fs.readFileSync on it. We hit exactly that shape (node:os?tsx-namespace=...) while building the Sanity SDK on Node 24 with tsx 4.22.3, in a code path where the #802 resolve bug never fired, so the two are independent surfaces.

It's the same family as #750 (data: URLs); the open PRs #751 / #756 only special-case data:. A general fix would strip tsx-internal query params (tsx-namespace=, tsx-commonjs-export-preparse=, tsx-commonjs-virtual-query=) from any non-file: URL before delegating to nextLoad. I have a working patch for that and can open it as a separate issue + PR.

FWIW I couldn't reproduce the builtin ENOENT with a minimal tsImport() → CJS-context .ts → import('node:crypto') chain on 4.22.3–4.23.1; simple builtin imports pass through cleanly, and in deeper chains the resolve bug in this issue fires first. Your case (cwd-prefixed <cwd>/node:crypto?...) likely has an extra ingredient, probably a longer require() chain, so a minimal repro in a new issue would help pin it down.

Also confirmed: the repro in this issue still fails on 4.23.1 / Node 24.15.0, so #802 remains current.