The issue involves deep architectural changes and maintainer feedback suggests significant complexity.
The issue describes unexpected behavior in module customization hooks related to `require`, specifically around the resolution of CJS specifiers and the handling of `file://` URLs. The maintainers indicate that the current approach may be fundamentally flawed and suggest reverting to previous methods. This requires deep architectural knowledge and understanding of Node.js internals, making it a complex and high-risk issue.
It seems I am one of the early adopters of module hooks.
I liked the idea of the module customization hooks, and tried to use it in my project.
However, I believe the current behavior of require handling in the esm loader is buggy.
Relevant source code, here https://github.com/nodejs/node/blob/69f8794cbea5813ff9abb490c2cd875b8332f605/lib/internal/modules/esm/translators.js#L130-L159
The resolving of the specifier is done in the main thread, using Module._resolveFilename, before being sent to the customization hooks.
The resolver hook is then receiving a resolved file:// URL, instead of the real specifier.
These are not expected according to the documentation of the module customization hooks. And for my use case, it has made the hooks useless.
To make it clear there are two bugs:
Module._resolveFilename will throw an error in the first place.specifier, if the first bug would not trigger.The root of this issue might be the default resolver in customization hooks does not support resolving CJS modules.
An easy fix would be to move the Module._resolveFilename into the default resolver.
The loading of .node native add-ons may also get in the way.
But IMO it should also go through the hooks, and eventually be loaded as {type: 'commonjs', source: undefined, url: 'file://... .node'}
Claim this issue to let others know you're working on it. You'll earn 10 points when you complete it!