Repository navigation
Should we backport node_module_version to v4.x? #124
Description
This question was raised in an issue over at https://github.com/nodejs/node
Thoughts @nodejs/lts?
/cc @bnoordhuis
node_module_version to v4.x? #124This question was raised in an issue over at https://github.com/nodejs/node
Thoughts @nodejs/lts?
/cc @bnoordhuis
Activity
rvagg commentedon Jul 19, 2016
I believe this will come across if we pull in nodejs/node#6994 which is already on the agenda.
Fishrock123 commentedon Jul 19, 2016
Anyone able to provide a synopsis of that that does? I'm not familiar with it.
saper commentedon Jul 20, 2016
@Fishrock123 This adds
process.config.variables.node_module_versiontoconfig.gypi. This information is available asprocess.versions.modulesif 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 commentedon Jul 20, 2016
(Proof of concept: backport of
node_module_versionto node v0.10: nodejs/node#7808 )jasnell commentedon Jul 20, 2016
It is worth noting that
process.configis frequently overridden by certain userland modules and depending onprocess.configis unwise. We've had regressions creep up recently in v4 because of the addition of FIPS mode checks inprocess.configthat failed because a userland module decided to overwriteprocess.configentirely.bnoordhuis commentedon Jul 20, 2016
The difference though is that
node_module_versionis also available in a binding.gyp.mhdawson commentedon Jul 20, 2016
Does seem useful and as a backport at least for 4.x
jasnell commentedon Aug 8, 2016
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 commentedon Aug 19, 2016
v4.x version is in nodejs/node#8171
MylesBorins commentedon Nov 14, 2016
This landed 🎉