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
npm v6 would not attempt to install optionalDependencies if their platform (os/cpu) or engines (node/npm) did not match the current environment. npm v7 broke this behavior by accident, always attempting to install optionalDependencies in a mismatched environment.
We have a fix, but found that npm v6 also had the behavior where it would install those optionalDeps if --force is used.
I think the correct behavior is to never install optionalDependencies on mismatched environments, even if --force is set.
Motivation ("The Why")
Installing platform-mismatched optionalDependencies can cause big problems. For example, a package may have a set of os/cpu specific binary packages listed as optionalDependencies, specifically to ensure that they do not get the wrong one installed for a given user. It would be surprising if --force caused all of them to be installed.
We currently tell users to use --force to accept conflicting peerDependencies, so the scope of installs where users might be setting --force has increased. (Also, the message is much less foreboding now. "Recommended protections disabled" rather than "I sure hope you know what you are doing", so fewer users will be scared by it.)
Presumably, the dependencies are optional anyway, so it's fine (or at least, a technically correct package resolution) if they're missing.
Currently (as of 7.5.4) npm installs all optionalDependencies, including those with mismatched os/cpu/node version. (Build failures are ignored and the package removed, but of course this doesn't help precompiled binary packages that don't have a build step.)
The fix that restores v6 behavior will install optionalDependencies with mismatched os/cpu/node version if --force is set.
Desired Behaviour
Never install optional dependencies with mismatched os/cpu/node version environments, even if --force is set.
isaacs
changed the title
[RRFC] Drop support for installing other-platform optionalDependencies with --force
Drop support for installing other-platform optionalDependencies with --force
Feb 17, 2021
Discussed in RFC meeting. The hazard of not installing any given optional dep (especially one that declares a mismatched platform) is quite small. And users who want the optionalDep in spite of the platform mismatch can install with --force as a regular dependency.
This is implemented in npm/arborist#231 and will be in the next CLI release.
npm v6 would not attempt to install optionalDependencies if their platform (os/cpu) or engines (node/npm) did not match the current environment. npm v7 broke this behavior by accident, always attempting to install optionalDependencies in a mismatched environment.
We have a fix, but found that npm v6 also had the behavior where it would install those optionalDeps if
--force
is used.I think the correct behavior is to never install optionalDependencies on mismatched environments, even if
--force
is set.Motivation ("The Why")
--force
caused all of them to be installed.--force
to accept conflicting peerDependencies, so the scope of installs where users might be setting--force
has increased. (Also, the message is much less foreboding now. "Recommended protections disabled" rather than "I sure hope you know what you are doing", so fewer users will be scared by it.)Example
http://registry.npmjs.org/@netlify/traffic-mesh-agent
How
Current Behaviour
Currently (as of 7.5.4) npm installs all optionalDependencies, including those with mismatched os/cpu/node version. (Build failures are ignored and the package removed, but of course this doesn't help precompiled binary packages that don't have a build step.)
The fix that restores v6 behavior will install optionalDependencies with mismatched os/cpu/node version if
--force
is set.Desired Behaviour
Never install optional dependencies with mismatched os/cpu/node version environments, even if
--force
is set.References
cc: @eduardoboucas
The text was updated successfully, but these errors were encountered: