Skip to content

Can we report the node versions, in addition to the ABI version, on ABI mismatch? #27100

Description

@sam-github

I recently answered a question about this:

internal/modules/cjs/loader.js:718
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: The module '/lib/node_modules/fs-ext/build/Release/fs-ext.node'
was compiled against a different Node.js version using
NODE_MODULE_VERSION 57. This version of Node.js requires
NODE_MODULE_VERSION 64. Please try re-compiling or re-installing
the module (for instance, using `npm rebuild` or `npm install`).

This is a pretty good error message, and it does say what people should do to fix the problem, but most people have no idea what module versions are, that they can be different for different release lines, or how to find out what release line a module version was associated with. This can confuse them. The person who asked me about the above thought the npm package they were using somehow just didn't support node 10.x.

It would take a (small) amount of extra tracking on our part, but I think it would be helpful if that message was enhanced to list the node.js major's that a module version could correspond to. It might help cut down the number of questions just a little bit more.

Is your feature request related to a problem? Please describe.
Please describe the problem you are trying to solve.

Describe the solution you'd like
Please describe the desired behavior.

Describe alternatives you've considered
Please describe alternative solutions or features you have considered.

Activity

  1. added
    feature requestIssues requesting new Node.js features.
    good first issueIssues that are suitable for first-time contributors.
    on Apr 5, 2019
  2. sam-github commented on Apr 5, 2019

    @sam-github
    ContributorAuthor

    Note: while in theory module versions can remain the same between major's, it seems every one of 6, 8, 10, 11, 12 have different module ABI versions, so that can simplify the message, and also make it easier to just put the node.js version in parentheses after the ABI version. Or... perhaps list the node.js version in first place, with the module ABI version in parentheses after? So the info people are most likely to recognize is more prominent?

  3. richardlau commented on Apr 5, 2019

    @richardlau
    Member

    Should be quite easy for the required module/Node.js version as that is known at compile time:

    node/src/node_binding.cc

    Lines 501 to 511 in f9ddbb6

    snprintf(errmsg,
    sizeof(errmsg),
    "The module '%s'"
    "\nwas compiled against a different Node.js version using"
    "\nNODE_MODULE_VERSION %d. This version of Node.js requires"
    "\nNODE_MODULE_VERSION %d. Please try re-compiling or "
    "re-installing\nthe module (for instance, using `npm rebuild` "
    "or `npm install`).",
    *filename,
    mp->nm_version,
    NODE_MODULE_VERSION);

    NODE_MODULE_VERSION:

    #define NODE_MODULE_VERSION 68

    We could just as easily also include NODE_VERSION:

    #define NODE_VERSION "v" NODE_VERSION_STRING

    The mismatched module version being loaded, however, would require some sort of mapping to Node.js versions. Something like #24114 (but this would need to be embedded). But it could always be a module version we don't know of yet (i.e. someone compiles against a later version of Node.js (e.g. 13) and attempts to run on an earlier Node.js.

  4. richardlau commented on Apr 5, 2019

    @richardlau
    Member

    Although if we include the Node.js version that might affect embedders like Electron?

  5. targos commented on Apr 5, 2019

    @targos
    Member

    If #24114 lands, we could just add a link to it.

  6. sam-github commented on Apr 5, 2019

    @sam-github
    ContributorAuthor

    I worry that for people whom the current text is not enough, a link to the registry might not be enough either, though a link to a specific section describing what is going on might be a reasonable enhancement, or even an alternative to displaying node versions in the message.

    I usually see this when people upgrade, so newer node would know the older modules version, but the opposite does happen, too.

    I'd be happy to backport new module versions as they are allocated into older node LTS lines so they "know" about newer module version values, though of course that wouldn't help people who aren't up to date on their LTS line.

  7. cedric05 commented on Apr 18, 2019

    @cedric05

    #24114 landed. shall i look?

  8. sam-github commented on Apr 18, 2019

    @sam-github
    ContributorAuthor

    Sure, see what you can do. Maybe its impossible to make this clear enough, but a link to the registry, or perhaps a link to a page in the node docs that explains the problem in more detail and that then links to the registry, would help a bit.

  9. cedric05 commented on Apr 21, 2019

    @cedric05

    abi_version_registry doc is not there in nodejs docs. what are viable options now? shall i link github one?

  10. sam-github commented on Apr 22, 2019

    @sam-github
    ContributorAuthor

    Maybe if the doc generation process processed the json into a nice table in one of the doc pages then a link to the docs would make sense, but until/unless someone does that, github is more likely to be up to date, so direct linking is a good idea.

  11. rexagod commented on Jun 15, 2019

    @rexagod
    Member

    Can I work on this one? Thanks!

  12. sam-github commented on Jun 17, 2019

    @sam-github
    ContributorAuthor

    Its not incredibly clear what can be done to improve the situation, but if you think you can, please give it a shot, you don't have to ask for permission!

  13. Josverl commented on Aug 24, 2019

    @Josverl

    just fyi: the error message is the only method I have been able to find that provides details on the ABI version of a compiled module.

    I need to use it in order to try and determine/verify the versions provided via prebuild-install, and use a regex to parse the modules ABI version information out or the error message

    I realize that this is a poor substitute for an actual API to determine the ABI
    but I I would love for the regex to keep working if the error message is changed . unless there is a better method to determine the same

    checkABI.js

  14. sam-github commented on Sep 4, 2019

    @sam-github
    ContributorAuthor

    There doesn't seem much to do about this, so I'll close it

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.good first issueIssues that are suitable for first-time contributors.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions