NODE_MODULE_VERSION for Electron Major Releases

[codebytere]

Related to #621
See Also: electron/node-abi#55

At present Electron has the same ABI number for Electron 3 and Electron 4, when in reality the ABI changed between them and so this is causing issues for some consumers.

Would it be possible for us to get our own ABI versions for each major Electron release?

cc @MarshallOfSound

[mcollina]

Given that Electron is an embedder of Node.js, what is currently blocking you to do this?

Will it have any downsides?

[mhdawson]

I think there has been some earlier discussion along these lines. I don't think Node.js would do any releases etc. instead what would be needed is so that the format of the ABI number be structured so that embedders would add their own versions without overlapping each other of further Node.js versions. I think @ofrobots had suggested possibly assigning some of the higher bits for this purpose.

[mhdawson]

I see the issue above #621 is where @ofrobots made his suggestion :). I also see that @rvagg had an alternate approach where there would be a registry with a way to reserve numbers.

I guess the action being requested is for us (Node.js) to agree/decide on one of these approaches.

[MarshallOfSound]

I guess the action being requested is for us (Node.js) to agree/decide on one of these approaches.

Pretty much 😄

We've been following along with these issues and the PR that @rvagg raised but now this has actually manifested as an issue with Electron 3 vs 4 we need to get a unique ABI number. Either the higher-order-bit, an allocated range, or laying claim to a number in a registry works for us (although the higher-order-bit or an allocated range would be easier for us to manage). Just need Node.JS to say "do this" 😀

[Trott]

Is it too early to put a tsc-agenda label on this just to get a decision made?

[mhdawson]

I'd say add it to the agenda so we can discuss and get agreement (if we can) on which of the two directions is preferred. Bits or registry. I'll add, if people disagree please let me know and we can remove.

[gabrielschulhof]

I'm concerned about #621 (comment) (explosion of binaries with different versions numbers for pre-compiled addon providers to maintain). There are also two issues here, AFAICT:

1. For maintainers to know which Node.js version ships which ABIs, and
2. For the addon to advertise which (combination of) Node.js ABIs it supports.

I believe that, if we are to avoid the combinatorial explosion resulting from assigning version numbers to each ABI Node.js exposes, we need more than just vendor plus Node.js ABI version in the nm_version field. We also need a way for the field to indicate that the module does not care about, say, the openssl ABI version. So, we need to further partition the bits, and have a zero in a given field indicate that the module does not care about that particular ABI. This would be true for all ABI-related fields except the highest order one, which would be the vendor field, where a zero would indicate that the module is designed to run against vanilla Node.js.

The registry approach, although AFAICT more open-ended, I don't think allows modules to indicate which ABIs they don't care about.

Do we have a list of ABIs whose version would influence the final version number advertised by the addon? I'm thinking, like,

ABI
vendor
V8
openssl
libuv
ICU(?)
c-ares(?)

We can also make struct node::node_module a variable-length structure where the fields currently present would be followed by a new field indicating how many ABI versions follow and then a sequence of ABI versions. A value of -2 in nm_version (-1 is taken by N-API) would then indicate to the addon loader that it needs to consult the ABI versions in detail.

[mcollina]

How is this could affect prebuilt libraries? Could an author load a different prebuilt based on this composed ABI?

[gabrielschulhof]

@mcollina the prebuild creation tools like node-pre-gyp and prebuild would have to be updated to deal with all these new versions that Node.js exposes and encode them in the file names that get uploaded, but, if authors do not care about most of the ABIs they would still only need to build a few binaries for the combinations they care about.

[gabrielschulhof]

There's another aspect too. We are trying to move addons towards using a special symbol for startup rather than node::node_addon + a library constructor, because library constructors only get called once per process, so such addons would not support workers and/or multiple contexts.

Currently the special symbol's name includes the module version. It's declared, like,

void node_register_module_v64(v8::Local<v8::Object> exports,
                              v8::Local<v8::Object> module,
                              v8::Local<v8::Context> context);

with the help of src/node.h#L540-L560

So, if we want such an addon to first report the ABI versions it supports, we might want to make this a two-step process where the special symbol is a function that returns the list of ABIs supported and the entry point for the addon.