`import-in-the-middle` causes exception when creating `ERR_MODULE_NOT_FOUND` message

[timfish]

Version

v22.1.0

Platform

All

Subsystem

module

What steps will reproduce the bug?

This was triggered by a combination of import-in-the-middle and tsx, but below is a minimal reproduction without either of those.

• import-in-the-middle sets parentURL to node build-ins (node:*).
• tsx tries to resolve files that do not exist

The

hook.mjs

export async function resolve(specifier, context, nextResolve) {
 specifier = 'file:///dost-not-exist.mjs';
 context.parentURL = 'node:util';
 return nextResolve(specifier, context);
}

index.mjs

import { register } from "node:module";

register('./hook.js', import.meta.url);
await import("node:util");

Which gives the following error:

TypeError [ERR_INVALID_URL_SCHEME]: The URL must be of scheme file
 at fileURLToPath (node:internal/url:1491:11)
 at finalizeResolution (node:internal/modules/esm/resolve:265:42)
 at moduleResolve (node:internal/modules/esm/resolve:924:10)
 at defaultResolve (node:internal/modules/esm/resolve:1148:11)
 at nextResolve (node:internal/modules/esm/hooks:750:28)
 at resolve (data:application/javascript;base64,CiAgICBleHBvcnQgYXN5bmMgZnVuY3Rpb24gcmVzb2x2ZShzcGVjaWZpZXIsIGNvbnRleHQsIG5leHRSZXNvbHZlKSB7CiAgICAgIHNwZWNpZmllciA9ICdmaWxlOi8vL2Rvc3Qtbm90LWV4aXN0Lm1qcyc7CiAgICAgIGNvbnRleHQucGFyZW50VVJMID0gJ25vZGU6dXRpbCc7CiAgICAgIHJldHVybiBuZXh0UmVzb2x2ZShzcGVjaWZpZXIsIGNvbnRleHQpOwogICAgfQo=:5:14)
 at nextResolve (node:internal/modules/esm/hooks:750:28)
 at Hooks.resolve (node:internal/modules/esm/hooks:238:30)
 at MessagePort.handleMessage (node:internal/modules/esm/worker:199:24)
 at [nodejs.internal.kHybridDispatch] (node:internal/event_target:821:20) {
 code: 'ERR_INVALID_URL_SCHEME'
}

This is caused by this code where base is node:util:

node/lib/internal/modules/esm/resolve.js

Lines 264 to 265 in 87b87a8

	throw new ERR_MODULE_NOT_FOUND(
	path || resolved.pathname, base && fileURLToPath(base), resolved);

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

Every time

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

This should throw a valid ERR_MODULE_NOT_FOUND error

What do you see instead?

It's throwing while creating the message

Additional information

This was made incredibly difficult to debug because you can't debug loader hooks!

Credit to @nwalters512 for the back and forth debugging with me!

[avivkeller]

Thanks for the issue, if you want to submit a patch, feel free to do so, if not, I'm sure a member of the team will be happy to assist

[avivkeller]

@nodejs/loaders correct me if I'm wrong, but wouldn't this behavior also cause errors in the experimental HTTP import system?

[GeoffreyBooth]

This seems like expected behavior to me. It can't create a URL with that parent. It can't determine that the module doesn't exist if it can't first figure out what URL to try to retrieve.

[avivkeller]

Ack, didn't mean to add that label, I was looking to see if we had a "bug" label and I must've misclicked it

[nwalters512]

Node is already correctly determining that the file does or does not exist. As described above in the original issue, the error we're encountering actually occurs when Node tries to construct the ERR_MODULE_NOT_FOUND error to throw.

I agree that the situation that import-in-the-middle gets us into (parentURL === 'node:util') is a weird one, but Node is so close to handling it in a sensible way. For instance, if fileURLToPath(base) errored out while constructing the ERR_MODULE_NOT_FOUND error, it could instead use base verbatim.

[avivkeller]

This seems like expected behavior to me. It can't create a URL with that parent. It can't determine that the module doesn't exist if it can't first figure out what URL to try to retrieve.

Even so, IMO a more descriptive error may be helpful, rather than the one thrown by the conversion utility

node:util is not a valid <...>?

[timfish]

It can't determine that the module doesn't exist if it can't first figure out what URL to try to retrieve.

It has already determined that the module doesn't exist, it's just trying to construct the error message when it throws.

I can't see how this is expected behaviour. the code assumes base is a file URL and it is not.

If parentURL can only be a file URI and never a node: URI (or any other URI!) this should be enforced earlier in resolve.

Just be aware that enforcing this in resolve will break import-in-the-middle and everything that relies on it!

[GeoffreyBooth]

If parentURL can only be a file URI and never a node: URI (or any other URI!) this should be enforced earlier in resolve.

And if we did, what error would be thrown? Probably ERR_INVALID_URL_SCHEME, I’d think. In which case, why does it matter whether it’s thrown here or earlier?

[nwalters512]

Throwing earlier would ensure consistent behavior. Right now, everything happily works with a node:* parentURL provided that the file being resolved exists. I want Node to either always use the normal resolving behavior with parentURL = 'node:*', or always error out quickly and obviously.