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

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

[sam-github]

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?

[richardlau]

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:

node/src/node_version.h

Line 118 in f9ddbb6

#define NODE_MODULE_VERSION 68

We could just as easily also include NODE_VERSION:

node/src/node_version.h

Line 65 in f9ddbb6

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

[richardlau]

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

[targos]

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

[sam-github]

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.

[cedric05]

#24114 landed. shall i look?

[sam-github]

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.

[cedric05]

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

[sam-github]

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.

[rexagod]

Can I work on this one? Thanks!

[sam-github]

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!

[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