You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When npm installs packages containing native code it compiles that native code against the modules version (process.versions.modules in node, or modules in npm --versions). When that same installed package is later run with a different node version, loading the compiled native code will fail due to a modules version mismatch. What is required in that case is an npm rebuild, when the package supports it, or npm ci (or similar) to reinstall the package and recompile the native code with the new version.
The Problem
The problem with this is detecting that there is a mismatch before it fails. There is currently no record of what the version of node + npm (and hence modules) was when the package was installed and compiled. For instance, as part of Transitive, an open-source framework for full-stack robotics software, we have an agent running on robots that will start other packages (think of them as apps). If we upgrade node on the robot, we need to recompile/reinstall all packages or else they would crash -- virtually all of them use packages containing native code, e.g., rclnodejs. Of course, we could keep our own record of what happened when, e.g., record what version of node was used when we first installed these apps. But this seems brittle and I would imagine many developers of solutions that involve node/npm as part of a product (open-source or not) having this issue.
Proposed Solution
A solution could be very simple: record process.versions.modules (or even all of process.versions) somewhere, e.g., in node_modules/the-installed-package/.compilation_versions.json in the moment the package installs/compiles, or in a central place where the information is indexed by the package name, e.g., in node_modules/.package-lock.json.
Bonus
For added bonus it would be awesome if npm install would then use that recorded information to check whether a package needs to be rebuilt/reinstalled, but even without this, a record like this would already allow developers to detect the modules mismatch before it throws an exception.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
When npm installs packages containing native code it compiles that native code against the modules version (
process.versions.modules
in node, ormodules
innpm --versions
). When that same installed package is later run with a different node version, loading the compiled native code will fail due to a modules version mismatch. What is required in that case is annpm rebuild
, when the package supports it, ornpm ci
(or similar) to reinstall the package and recompile the native code with the new version.The Problem
The problem with this is detecting that there is a mismatch before it fails. There is currently no record of what the version of node + npm (and hence modules) was when the package was installed and compiled. For instance, as part of Transitive, an open-source framework for full-stack robotics software, we have an agent running on robots that will start other packages (think of them as apps). If we upgrade node on the robot, we need to recompile/reinstall all packages or else they would crash -- virtually all of them use packages containing native code, e.g., rclnodejs. Of course, we could keep our own record of what happened when, e.g., record what version of node was used when we first installed these apps. But this seems brittle and I would imagine many developers of solutions that involve node/npm as part of a product (open-source or not) having this issue.
Proposed Solution
A solution could be very simple: record
process.versions.modules
(or even all ofprocess.versions
) somewhere, e.g., innode_modules/the-installed-package/.compilation_versions.json
in the moment the package installs/compiles, or in a central place where the information is indexed by the package name, e.g., innode_modules/.package-lock.json
.Bonus
For added bonus it would be awesome if
npm install
would then use that recorded information to check whether a package needs to be rebuilt/reinstalled, but even without this, a record like this would already allow developers to detect the modules mismatch before it throws an exception.Beta Was this translation helpful? Give feedback.
All reactions