Skip to content

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

Closed
Closed
Improve the error messages instead of the generic "Error: Cannot find module 'xyz'"#5758
Labels
feature requestIssues requesting new Node.js features.moduleIssues and PRs related to the module subsystem.

Description

@drywolf
drywolf
opened on Mar 17, 2016
  • 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

Activity

  1. mscdex
    added
    moduleIssues and PRs related to the module subsystem.
    feature requestIssues requesting new Node.js features.
    on Mar 17, 2016

  2. MylesBorins commented on Mar 17, 2016

    @MylesBorins
    MylesBorins
    on Mar 17, 2016
    Contributor

    @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.

  3. MylesBorins
    closed this as completedon Mar 17, 2016

  4. MylesBorins commented on Mar 17, 2016

    @MylesBorins
    MylesBorins
    on Mar 17, 2016
    Contributor

    Perhaps an update to the docs might help with this

  5. drywolf commented on Mar 17, 2016

    @drywolf
    drywolf
    on Mar 17, 2016
    ContributorAuthor

    @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

  6. MylesBorins commented on Mar 17, 2016

    @MylesBorins
    MylesBorins
    on Mar 17, 2016
    Contributor

    @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

  7. drywolf commented on Mar 20, 2016

    @drywolf
    drywolf
    on Mar 20, 2016
    ContributorAuthor

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

  8. mxhold commented on Nov 3, 2018

    @mxhold
    mxhold
    on Nov 3, 2018

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    feature requestIssues requesting new Node.js features.moduleIssues and PRs related to the module subsystem.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions