ERR_MODULE_NOT_FOUND: add a property to exception object to hold failing import's argument

[rulatir]

Is your feature request related to a problem? Please describe.

I am developing a framework that uses node as a host for user scripts. The framework loads them dynamically with the async import() function, and the userscripts can also import other modules with import statement.

When I call that import() function, I basically want to rethrow all errors thrown by it, except for one very specific condition: when the import() function fails with ERR_MODULE_NOT_FOUND because the userscript file itself wasn't present in the location just tried. The userscript might still be found in some other search path, which is why its absence in any given candidate location is not an error. If however the import() function failed with ERR_MODULE_NOT_FOUND because some other module imported by the userscript was not found, then I want to rethrow that error.

Describe the solution you'd like

Add a property to the exception object thrown for ERR_MODULE_NOT_FOUND that will hold the exact value of the argument that was given to the failing import function or statement.

Describe alternatives you've considered

I considered checking for existence first and then attempting to import(), but that is a known antipattern.

I considered parsing the message or stack property, but that would be a hack. These properties are probably locale dependent and their format is not set in stone.

I looked into custom loaders and found the subject difficult, scary, apparently indefinitely experimental, and an overkill for this particular purpose. I need a simple and reliable way.

[DerekNonGeneric]

Thanks for raising this — the request sounds reasonable.

Hope to take a deeper look a bit later. Curious what others may think on the matter.

/cc @nodejs/modules

[ljharb]

A custom loader doesn't sound like overkill at all to me - it's precisely what you're trying to achieve. The other adjectives, however, are likely true at this time.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[rulatir]

@DerekNonGeneric is it "a bit later" yet? ;)

[GeoffreyBooth]

Doesn’t the error message included with ERR_MODULE_NOT_FOUND have the file path you’re asking for? Yes it’s inside an English sentence that you’d need to parse out, but even if the message itself changes in the future, code like error.description.includes(fullPathToUserScript) would work as long as the path to the missing module never gets removed (which is very unlikely). Seeing as your use case is very specific, I don’t know if it’s likely that Node will add this path as its own property on the error object.

[rulatir]

Yes it’s inside an English sentence

... when node is running with English locale.

[GeoffreyBooth]

… when node is running with English locale.

Does Node have non-English error messages when it’s running in other locales?

[rulatir]

Does Node have non-English error messages when it’s running in other locales?

It either has, or might have at some point in the future, which is still a sufficient reason not to rely on parsing natural language.

[ljharb]

Even if it wouldn’t ever be anything but English, i would think it’d be a horrifying suggestion to tell people to parse natural language. The message is for humans, only - the stuff for programs is “other properties”.

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[rulatir]

No bot, no. I'm still rooting for this.

[GeoffreyBooth]

Node.js recently added support for Error.cause: https://nodejs.org/api/errors.html#errorcause, e54ee80. I would assume that the ESM loader’s ERR_MODULE_NOT_FOUND error is thrown as a result of some file system “file not found”-type error; the earlier exception could be included in the cause property of the ERR_MODULE_NOT_FOUND exception. I would think that this should satisfy your use case.

[rulatir]

It wouldn't. I need the exact byte-for-byte string that was passed as the argument to import(), rather than the filesystem path it resolved to via a possibly unknown mapping function that may not even be invertible. I never said that what I pass to import is a fully resolved filesystem path. Those can well be module references to be resolved by the default loader, but still my code wants to be able to try several candidates in order, and if import() fails, I need to be able to distinguish whether it failed directly (try another candidate) or indirectly (fail).

EDIT: it might work if the entire chain down to the failed dependency is recorded using the cause references, i.e. ERR_MODULE_NOT_FOUND because ENOENT means a direct failure and ERR_MODULE_NOT_FOUND (because ERR_MODULE_NOT_FOUND)+ because ENOENT means an indirect failure.

[bnoordhuis]

Is the resolution here to add a custom loader with --experimental-loader? In the two years since this issue was raised loaders have been documented quite thoroughly.

My intuition is that adding more properties to the ERR_MODULE_NOT_FOUND exception object complicates writing third-party loaders but maybe I'm mistaken here.

[GeoffreyBooth]

Is the resolution here to add a custom loader

I think that's one way to achieve the request today, yes, but it's a bit much to write a custom loader to improve a Node error message. I think a reasonable solution would be to add the specifier of the failing import to the cause property of the error object. Pull requests are welcome.

[rulatir]

The rationale for my original request is not to improve error messages, though that would be an extra benefit. I need the feature to be able to implement special-purpose loading logic correctly in the first place, without resorting to the check-existence-and-load antipattern. As it is, the error doesn't supply necessary information to make the key decision in the algorithm: whether to try another candidate specifier (because this one didn't resolve to an existing file) or to rethrow (because the file was found, but contained errors).

I insist that the first question one asks when being presented with an error object is, "What failed?", and answering this question is the error object's primary job. In this case the specifier is the what.

Unless someone is doing something really exotic with ERR_MODULE_NOT_FOUND objects, like validating their structure against an inextensible schema, I can't imagine a scenario where adding a super-relevant property under already standardized cause subobject would "complicate writing third-party loaders".

[GeoffreyBooth]

my original request

@rulatir This request has been open for two years without anyone expressing interest in implementing this enhancement. If you want to see it happen you might need to make a PR yourself. A good place to start is https://github.com/nodejs/node/blob/main/CONTRIBUTING.md.

[rulatir]

@rulatir This request has been open for two years

... and custom loaders are still under a flag.

without anyone expressing interest in implementing this enhancement. If you want to see it happen you might need to make a PR yourself. A good place to start is https://github.com/nodejs/node/blob/main/CONTRIBUTING.md.

If I must in fact sit down and write the code myself, what provisions in the LICENSE compel or incentivize me to subject myself to new contributor hazing invest additional time and effort to conform to the contributing process? Can't I just happily use my fork in-house without ever distributing it to third parties? Why should I invest a difficult-to-estimate amount of time to study all the documents linked to from CONTRIBUTING.md to learn how to be a good nodejs contributor boy, all this striving and becoming just to be allowed to contribute what is likely to amount to ~10 LOC plus a paragraph of markdown?

[bnoordhuis]

Okay, close it is. I don't see this discussion taking a productive turn. @rulatir don't let the door hit you on the way out.