No, not by default. When an install fails, assistants often retry with the force option or the legacy peer deps option because those make the error disappear. Both remove checks npm put there on purpose. Treat the error as information, find the conflict, and let a human decide whether to bypass anything.
What the two options actually do
The npm configuration reference describes both. The force option "removes various protections against unfortunate side effects, common mistakes, unnecessary performance degradation, and malicious input." Among the things it allows: installing packages whose engines declaration needs a different Node or npm version, letting npm audit fix install modules outside your stated dependency range (including major version changes), and installing conflicting peer dependencies into the root project.
The legacy peer deps option causes npm to "completely ignore peerDependencies when building a package tree," as npm versions 3 through 6 did. The docs say that if a package cannot be installed because of overly strict colliding peer dependencies, it provides a way forward. They also say its use is not recommended, because it will not enforce the peer dependency contract that other packages may rely on.
So both options are escape hatches. They have valid uses. The problem is an agent reaching for them automatically, to make a red build green, with nobody reading the warning.
Why this matters for security
A peer dependency conflict usually means two packages disagree about which version of a third package they need. Ignoring that disagreement can leave you with a tree nobody designed. The code may run today and break, or behave differently, after the next update.
The force option is broader. It can let a version change land that your range was meant to block. That turns a quiet tooling error into an unreviewed upgrade. See when not to use audit fix with force for the audit side of this.
A safer way to handle the failure
- Read the error. npm names the packages in conflict. Copy that text into the pull request or ticket instead of discarding it.
- Find out who asks for what. Run
npm explainon the package in the message to see the chain of dependencies that pulled it in. - Try the boring fixes first. Upgrade or downgrade one of the two packages so their ranges overlap, or pick a different library.
- If you must bypass, scope it. Record why in the pull request, name the packages involved, and set a date to remove the bypass.
- Never bypass in CI by default. A shared pipeline that always uses an escape hatch hides every future conflict.
A short decision table:
| Situation | Reasonable response |
|---|---|
| Peer conflict between two direct dependencies | Align versions or swap one library |
| Engines mismatch on a tool you use locally | Update Node, or pick a compatible version |
| Agent added force to a lockfile install in CI | Revert, then ask why the install failed |
| Legacy library with no newer release | Bypass with a recorded reason and an expiry date |
Tell the assistant the rule up front
Assistants follow instructions better than they follow unwritten norms. Add one line to your agent instruction file: if an install fails, report the error and stop, do not add force or legacy peer deps. Pair it with a reviewer habit of searching the diff for those option names in scripts, CI files and .npmrc. A search for the words takes seconds.
An instruction is guidance, not enforcement. If you want a hard stop, add a check in CI that fails when those options appear in configuration you did not approve.
Quick check
Is the legacy peer deps option ever acceptable?
Sometimes, for an older library that has no newer release. Treat it as a recorded exception with an owner and an expiry date, not a default.
Does the force option only affect the install command?
No. The npm reference lists other effects too, including letting audit fix install versions outside your stated range. Check where it is set before trusting a clean run.
Safeguard policies and gates can be applied to pull requests, which gives a reviewer a second look at dependency changes. The CLI (version 1.4.0) and the VS Code extension bring dependency checks closer to where the assistant works.
Sources
- npm Docs, config (force, legacy-peer-deps): https://docs.npmjs.com/cli/v11/using-npm/config
- npm Docs, npm explain: https://docs.npmjs.com/cli/v10/commands/npm-explain
Last reviewed: 19 October 2026.
