René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"CJS module customized by synchronous customization hooks uses synthetic `require` with any use of `--loader`","articleBody":"### Version\n\nAll versions 24.12.0 ~ 24.15.0 and 25.2.0 ~ 25.9.0\n\n### Platform\n\n```text\nLinux 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun  5 18:30:46 UTC 2025 x86_64 GNU/Linux\n```\n\n### Subsystem\n\nmodule\n\n### What steps will reproduce the bug?\n\n```javascript\n// hook.cjs\nrequire('module').registerHooks({\n  load(url, context, next) {\n    return url.endsWith('entry.js') ? {\n      source: 'console.log(\"intercepted\", require.cache)',\n      format: 'commonjs',\n      shortCircuit: true\n    } : next(url, context)\n  }\n})\n```\n\nplus empty files `empty.mjs` and `entry.js`\n\n```shell\n$ node --no-warnings -r ./hooks.cjs --loader ./empty.mjs ./entry.js\n```\n\n### How often does it reproduce? Is there a required condition?\n\nAlways\n\n### What is the expected behavior? Why is that the expected behavior?\n\nLogs:\n1. `intercepted`, showing the loading of `entry.js` was customized by the synchronous `load` hook\n2. The `require.cache` object\n\nThe [docs](https://nodejs.org/docs/v25.9.0/api/module.html#asynchronous-loadurl-context-nextload) mention, in part, under \"Asynchronous `load(url, context, nextLoad)`\":\n\n\u003e When a `source` is provided, [...] only a subset of the CommonJS API will be available (e.g. no `require.extensions`, no `require.cache`, no `require.resolve.paths`) and monkey-patching on the CommonJS module loader will not apply.\n\u003e These caveats do not apply to the synchronous `load` hook, in which case the complete set of CommonJS APIs available to the customized CommonJS modules\n\nThis is, as far as I can tell, the only mention of this \"synthetic `require`\" behavior. And it should not apply to this case as the module is only customized by a synchronous `load` hook. There are no asynchronous customization hooks registered.\n\n### What do you see instead?\n\nLogs: `intercepted undefined`\n\nThis shows `entry.js` is using the synthetic `require`, despite what the docs say.\n\nThe mere *use* of the `--loader` flag triggers this, even when using empty file as a loader (so no asynchronous customization hooks are registered). Using `module.register` to register a loader file behaves the same as the `--loader` flag. The only way to avoid the synthetic `require` behvaior is to not use `--loader` or `module.register` at all.\n\n### Additional information\n\nFor a few weeks now I have been trying to migrate Yarn to synchronous customization hooks in response to #62012. The current stopgap we introduced in Yarn 4.14.0 falls into the documented caveats of \"synthetic `require`\" mentioned above. See https://github.com/nodejs/node/issues/62012#issuecomment-4282758016\n\nThe issue reported here means that to properly fix to #62012 on our end, we can't just move module loading via our fs patch layer to synchronous hooks. Instead we must do an all-or-nothing migration from `--loader` into `module.registerHooks`.","author":{"url":"https://github.com/clemyan","@type":"Person","name":"clemyan"},"datePublished":"2026-05-01T04:07:00.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/63060/node/issues/63060"}