Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork32.2k
Description
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 ofrequire handling in the esm loader is buggy.
Relevantsource code, here
node/lib/internal/modules/esm/translators.js
Lines 130 to 159 in69f8794
| constrequireFn=functionrequire(specifier){ | |
| letimportAttributes=kEmptyObject; | |
| if(!StringPrototypeStartsWith(specifier,'node:')&&!BuiltinModule.normalizeRequirableId(specifier)){ | |
| // TODO: do not depend on the monkey-patchable CJS loader here. | |
| constpath=CJSModule._resolveFilename(specifier,module); | |
| switch(extname(path)){ | |
| case'.json': | |
| importAttributes={__proto__:null,type:'json'}; | |
| break; | |
| case'.node': | |
| returnwrapModuleLoad(specifier,module); | |
| default: | |
| // fall through | |
| } | |
| specifier=`${pathToFileURL(path)}`; | |
| } | |
| constjob=cascadedLoader.getModuleJobForRequireInImportedCJS(specifier,url,importAttributes); | |
| job.runSync(); | |
| returncjsCache.get(job.url).exports; | |
| }; | |
| setOwnProperty(requireFn,'resolve',functionresolve(specifier){ | |
| if(!StringPrototypeStartsWith(specifier,'node:')){ | |
| constpath=CJSModule._resolveFilename(specifier,module); | |
| if(specifier!==path){ | |
| specifier=`${pathToFileURL(path)}`; | |
| } | |
| } | |
| const{url:resolvedURL}=cascadedLoader.resolveSync(specifier,url,kEmptyObject); | |
| returnurlToFilename(resolvedURL); | |
| }); |
The resolving of thespecifier is done in the main thread, usingModule._resolveFilename, before being sent to the customization hooks.
The resolver hook is then receiving a resolvedfile:// URL, instead of the realspecifier.
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:
- The cjs specifiers are being resolved in the wrong thread.
The hooks, therefore, cannot really work, because if the "expected" file does not really exist on the hard drive. The cjsModule._resolveFilenamewill throw an error in the first place. - The resolve hook is receiving a wrong
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 theModule._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'}