Skip to content

Unexpected behavior in module customization hooks / loader, for require #55808

Open
@nomagick

Description

@nomagick

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

const requireFn = function require(specifier) {
let importAttributes = kEmptyObject;
if (!StringPrototypeStartsWith(specifier, 'node:') && !BuiltinModule.normalizeRequirableId(specifier)) {
// TODO: do not depend on the monkey-patchable CJS loader here.
const path = CJSModule._resolveFilename(specifier, module);
switch (extname(path)) {
case '.json':
importAttributes = { __proto__: null, type: 'json' };
break;
case '.node':
return wrapModuleLoad(specifier, module);
default:
// fall through
}
specifier = `${pathToFileURL(path)}`;
}
const job = cascadedLoader.getModuleJobForRequireInImportedCJS(specifier, url, importAttributes);
job.runSync();
return cjsCache.get(job.url).exports;
};
setOwnProperty(requireFn, 'resolve', function resolve(specifier) {
if (!StringPrototypeStartsWith(specifier, 'node:')) {
const path = CJSModule._resolveFilename(specifier, module);
if (specifier !== path) {
specifier = `${pathToFileURL(path)}`;
}
}
const { url: resolvedURL } = cascadedLoader.resolveSync(specifier, url, kEmptyObject);
return urlToFilename(resolvedURL);
});

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:

  1. 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 cjs Module._resolveFilename will throw an error in the first place.
  2. 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 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'}

Metadata

Metadata

Assignees

No one assigned

    Labels

    loadersIssues and PRs related to ES module loaders

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions