Improve the error messages instead of the generic "Error: Cannot find module 'xyz'"

[drywolf]

• Version: 4.2.6
• Platform: Windows 10 64-bit
• Subsystem: module.js

Hi,

I just had a case where node reported one of my local modules (referenced by "my-module": "file:../my-module") as missing with the default generic node error:

module.js:328
    throw err;
    ^

Error: Cannot find module 'my-module'
    at Function.Module._resolveFilename (module.js:326:15)
    at Function.Module._load (module.js:277:25)
    at Module.require (module.js:354:17)
    at require (internal/module.js:12:17)
    at Object.<anonymous> (C:\code\my-service\server\server.js:3:23)
    at Module._compile (module.js:410:26)
    at Object.Module._extensions..js (module.js:417:10)
    at Module.load (module.js:344:32)
    at Function.Module._load (module.js:301:12)
    at Function.Module.runMain (module.js:442:10)

When I looked in the node_modules folder the my-module subdirectory was there. From that point on I spent about 30 min to an hour to figure out why node didn't recognize the module that was clearly there.

In the end it turned out that the entry file for the my-module (specified in package.json "main") was missing inside the node_modules\my-module folder. So the actual fix took about 15 seconds but the time it took to figure out what npm / node where trying to tell me about the error was way too long.
(for sure I will look immediately for the main file next time, but I'm raising this issue to help others not waste time on the same thing)

My suggestion would be to add additional checks to see if the "main" file for a package is really available at the configured path from package.json (probably here).

So if the file is missing the node should produce a more helpful error in the future.

Please let me know what you think about this, once I have some feedback I might work on PR for this.

Thanks

[MylesBorins]

@drywolf thanks for submitting this!

The module spec is currently locked and it is very unlikely that there will be any changes, especially breaking changes. Currently the project has treated changing error messages as a Semver-Major change, which would mean even if a change was approved it would never make it to v4.

I'm going to close for now, but feel free to keep the conversation going.

[MylesBorins]

Perhaps an update to the docs might help with this

[drywolf]

@thealphanerd Thanks for the reply.

I think some hint in the docs is a good idea at this point when it can't be incorporated into the software.
My idea would be to add a short note about the error-handling behavior for this case to the "Folders as Modules" section in the docs.

I already read the contribution guidelines so I can create a PR for this change, what is not entirely clear to me is if I need to make my changes to the docs on a separate branch or just on the master branch ?

Thanks

[MylesBorins]

@drywolf I don't believe we have a set process for that, but in general I always use a separate branch to be explicit.

Make sure you review the guidelines for commit messages, specifically that the title should include the subsystem, in this case doc: and be no longer than 50 characters. There should then be a space between that and the comment. The comment should wrap lines to 72 characters.

For example

doc: only 50 characters max

Here is where I say more, no more than 72 characters

[drywolf]

@thealphanerd Thanks for the hints. I created a PR which adds a note about this behavior to the modules section of the documentation.

[mxhold]

Is this something that could be revisited or are we stuck with this misleading error forever? I just spent an hour going through the exact same debugging process mentioned above of trying to figure out why a module couldn't be found when I had accidentally specified the package main file incorrectly. I even viewed the exact doc page where the note about this was added but I missed it. It would be great if the error message called out the main file problem specifically so as to prevent other people from running into this same problem in the future.