Should we backport `node_module_version` to v4.x?

[MylesBorins]

This question was raised in an issue over at https://github.com/nodejs/node

Thoughts @nodejs/lts?

/cc @bnoordhuis

[rvagg]

I believe this will come across if we pull in nodejs/node#6994 which is already on the agenda.

[Fishrock123]

Anyone able to provide a synopsis of that that does? I'm not familiar with it.

[saper]

@Fishrock123 This adds process.config.variables.node_module_version to config.gypi. This information is available as process.versions.modules if the node is running, but we don't know the value if we are for example cross-compiling a module for some node version other than currently running. See nodejs/node-gyp#855 and nodejs/node-gyp#855 (comment)

[saper]

(Proof of concept: backport of node_module_version to node v0.10: nodejs/node#7808 )

[jasnell]

It is worth noting that process.config is frequently overridden by certain userland modules and depending on process.config is unwise. We've had regressions creep up recently in v4 because of the addition of FIPS mode checks in process.config that failed because a userland module decided to overwrite process.config entirely.

[bnoordhuis]

The difference though is that node_module_version is also available in a binding.gyp.

[mhdawson]

Does seem useful and as a backport at least for 4.x

[jasnell]

The @nodejs/lts WG discussed this today, and while we didn't see a pressing justification for backporting it, we also couldn't come up with any objections. So... SGTM

[saper]

v4.x version is in nodejs/node#8171