Request: Backport loader fix to v22.x

Version

22.x

Platform

macOS 26.2 (arm64)
Node.js: v22.22.0
Package manager: npm 10.9.4

Subsystem

N/A

What steps will reproduce the bug?

I would like to request a backport of the fix that resolved an issue in v24.11.1 to the v22.x release line.

We are currently experiencing an issue that was fixed in v24.11.1. However, our project is still supporting v22.x and would benefit from having this fix backported.

import module from 'node:module'

module.registerHooks({
  load(url, context, defaultLoad) {
    return defaultLoad(url, context)
  },
})

await import('@intlify/unplugin-vue-i18n/vite')

How often does it reproduce? Is there a required condition?

Node.js < v24.11.1

What is the expected behavior? Why is that the expected behavior?

No errors

What do you see instead?

node:internal/modules/esm/translators:152
    return cjsCache.get(job.url).exports;
                                ^

TypeError: Cannot read properties of undefined (reading 'exports')
    at require (node:internal/modules/esm/translators:152:33)
    at Object.getPkg (/private/tmp/tsdown_issue_example/node_modules/jsonc-eslint-parser/lib/parser/visitor-keys.js:40:28)
    at loadNewest (/private/tmp/tsdown_issue_example/node_modules/jsonc-eslint-parser/lib/parser/modules/require-utils.js:73:26)
    at getVisitorKeys (/private/tmp/tsdown_issue_example/node_modules/jsonc-eslint-parser/lib/parser/visitor-keys.js:21:51)
    at Object.<anonymous> (/private/tmp/tsdown_issue_example/node_modules/jsonc-eslint-parser/lib/index.js:40:57)
    at loadCJSModule (node:internal/modules/esm/translators:166:3)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:202:7)
    at ModuleJob.run (node:internal/modules/esm/module_job:343:25)
    at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:665:26)
    at async file:///private/tmp/tsdown_issue_example/start.js:10:1

Additional information

Potentially Related PRs

Based on my investigation, the fix may have been introduced in one or both of these PRs:

downstream issue: rolldown/tsdown#766

Hey, none of both pointed PR are landed in v24.x; can you please be more specific with the "solved issue"? W/out knowing what to backport, it is too hard.

According to the v24.11.1 changelog:

[[ffbc0ae60a](https://github.com/nodejs/node/commit/ffbc0ae60a)] - module: refactor and clarify async loader hook customizations (Joyee Cheung) [#60278](https://github.com/nodejs/node/pull/60278)
[[6ed6062f7d](https://github.com/nodejs/node/commit/6ed6062f7d)] - module: handle null source from async loader hooks in sync hooks (Joyee Cheung) [#59929](https://github.com/nodejs/node/pull/59929)

These two PRs have been merged. I've also provided a minimal reproduction if you'd like to investigate the issue directly.

I think the fix is #59929 but this would incur a behavior change in v22 - in v22, --experimental-default-type still existed (it was removed in v23.4.0). In a few tests, the tests for that flag checks that when --experimental-default-type=module, require.cache in not available even in CommonJS modules, which is in conflict with #59929 that tries to ensure CommonJS are handled normally (with everything as usual in require) when it's not being customized by module.register.

IMO we should backport the fix and update test to test that "it's being handled by the ESM loader" differently. This would change it so that when --experimental-default-type=module, CommonJS modules still get a normal require instead of one that doesn't have many normal require properties. I doubt that's going to break much, since

--experimental-default-type is an early development feature already removed in a minor release (v23.4.0) and isn't even used all that much in the wild
NOT having require.cache is the more surprising/breaking behavior. Putting it back is less so.

cc @nodejs/loaders @nodejs/release WDYT

I agree with Joyee

Backport in #62029

esm: populate separate cache for require(esm) in imported CJS

module: only put directly require-d ESM into require.cache

module: use sync cjs when importing cts

module: handle null source from async loader hooks in sync hooks

module: fix sync resolve hooks for require with node: prefixes

module: do not wrap module._load when tracing is not enabled

module: do not invoke resolve hooks twice for imported cjs

This issue has been marked as stale due to 90 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.

Navigation Menu

Repository navigation

Request: Backport loader fix to v22.x #61801

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Potentially Related PRs

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Request: Backport loader fix to v22.x #61801

Description

Version

Platform

Subsystem

What steps will reproduce the bug?

How often does it reproduce? Is there a required condition?

What is the expected behavior? Why is that the expected behavior?

What do you see instead?

Additional information

Potentially Related PRs

Activity

juanarbol commented on Feb 13, 2026

sxzz commented on Feb 14, 2026

joyeecheung commented on Feb 25, 2026

JakobJingleheimer commented on Feb 27, 2026

joyeecheung commented on Feb 27, 2026

github-actions commented on Jul 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions