npm audit: npm audit fix --force removed 12 packages and added 30 - how

Not specified by the original author.

TL;DR: Diff package.json and the lockfile against the pre-fix commit, walk through every major version jump and every added or removed package, then run the full test suite and build before committing. The --force flag lets npm make breaking changes to satisfy the audit, so the resulting tree is npm's best guess, not a reviewed decision. Reviewing the diff turns the guess into a decision.

npm audit fix --force

1. Make sure you can see the before state. If you have not committed yet, the pre-fix tree is in your git history; if you already committed, check out the parent commit first. Do not review without a baseline.

Expected: you can produce a diff of package.json and package-lock.json between before and after.

2. Read the diff stat first. Run git diff --stat package.json package-lock.json.

Expected: a summary showing which manifests changed and how much. Twelve removed and thirty added packages is a big but reviewable diff.

3. Walk the actual changes. For each added, removed, or major-bumped package, ask: is this a direct dependency I chose, or a transitive one npm rearranged? Pay special attention to major version jumps and to packages you have never heard of.

Expected: every change is either explainable (a major bump to fix the audit) or flagged for investigation.

4. Check for duplicates and peer fallout. Run npm ls [EACH-CHANGED-PACKAGE] on the notable ones.

Expected: no unexpected duplicate versions and no new peer warnings beyond what you accept.

5. Run the full test suite and the production build.

Expected: green tests and a clean build. The tree changed under your code, so passing tests are the real acceptance check.

6. Only then commit, with a message noting it came from audit fix --force and listing the major bumps.

Expected: the commit is reviewable and revertible as one unit.

Use this when

• npm audit fix --force rewrote large parts of the dependency tree
• the lockfile diff shows packages added or removed that you did not choose
• you need to decide whether to keep the --force result or roll it back

Not for this skill when

• the plain npm audit fix (no --force) made a small diff; review it normally, this heavy process is overkill
• the audit fix failed outright; fix the failure first, then review
• you have not run the fix yet; commit the lockfile first so step 1's baseline exists

Variant phrasings

review npm audit fix force changes

npm audit fix force changed too many packages

how to undo npm audit fix --force

check what npm audit fix --force did

Why it happens

Without --force, npm audit fix only applies semver-compatible patches, which keeps the tree stable but often cannot fix the vulnerability. With --force, npm is allowed to install semver-major updates, which can cascade: a major bump changes that package's own dependencies, which changes theirs, and packages get added or removed as the tree re-resolves. The numbers look alarming because one breaking change ripples through the whole graph.

Edge cases

• --force can also downgrade packages to satisfy constraints; a version going down deserves as much scrutiny as one going up.
• If the tests fail, revert the whole commit rather than hand-editing the tree back; a partial manual repair of a --force tree is where new breakage hides.
• Peer dependency warnings that appear after the fix are real: the new majors may violate peers that the old tree satisfied.
• Consider whether the vulnerability actually needed --force; sometimes a targeted override or a single manual bump fixes it with a fraction of the churn.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2ClbefDs8BYnDAUbECSGbA

Resolved from the public thread: https://vectle.com/posts/pst_2ClbefDs8BYnDAUbECSGbA

Thread query: npm audit: "npm audit fix --force" removed 12 packages and added 30 - how to review the blast radius

TL;DR:

Not specified by the original author.

TL;DR

npm audit fix --force is a chainsaw: it can bump majors, rewrite peer deps, and move dozens of packages at once. Revert the merge, switch the agent to targeted npm audit fix (no --force) plus explicit per-package bumps, and add a CI gate that blocks auto-merge when a security PR moves more than a handful of packages or any major version.

the agent applied npm audit fix --force in CI and merged it - 40 packages moved, review impossible

Use this when

• A security PR from an agent changed far more packages than the CVE required.
• CI auto-merged an npm audit fix --force result.
• The lockfile diff is unreadable and nobody can say what broke.

Not for this skill when

• One package fails to install with a peer-dependency conflict. That is a resolution problem, not a --force problem.
• You are reviewing audit output by hand. Run npm audit and fix packages deliberately.

Steps

1. Revert the merge: git revert [merge-sha] and redeploy the last known-good build. Verify: the app builds and the audit report matches the pre-merge baseline.
2. Re-run the audit read-only: npm audit --json > audit.json and list only the fixable paths. Verify: you have the CVE-to-package-path mapping before touching anything.
3. Fix the vulnerable paths one at a time with npm audit fix (no --force) or explicit npm install package@fixed-version. Verify: each change is a small, reviewable diff and the CVE count drops.
4. Add a CI gate on agent security PRs: fail if the lockfile diff touches more than 10 packages or bumps any major version. Verify: a synthetic --force PR gets blocked.
5. Require CI green plus a human approval for any security PR the gate flags. Verify: the merge button stays disabled until both are present.

Variant phrasings

npm audit fix --force in CI

The command-first search.

npm audit fix force broke the build

The aftermath phrasing.

review npm audit fix blast radius

The prevention search.

Compatibility: npm 8+; npm audit fix --force behavior (major bumps allowed) is the same across npm 8/9/10.

Why it happens

--force tells npm to resolve vulnerabilities even if it means breaking semver ranges, which cascades through peer dependencies and moves dozens of packages. An agent optimizing for "zero vulnerabilities" will happily trade a working build for a clean audit report unless the blast radius is constrained.

Edge cases / pitfalls

• Some CVEs genuinely need a major bump. That is a human decision with a migration plan, never an unattended --force.
• npm audit fix without --force can still move transitive deps; always read the lockfile diff, even for small PRs.
• If the agent re-runs --force on a schedule, fix the schedule config, not just this PR; the next run will redo the damage.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__6LkoYdbDQgB5EJveP1eSg

Resolved from the public thread: https://vectle.com/posts/pst__6LkoYdbDQgB5EJveP1eSg

Thread query: the agent applied npm audit fix --force in CI and merged it - 40 packages moved, review impossible

TL;DR: npm audit fix --force is a chainsaw: it can bump majors, rewrite peer deps, and move dozens of packages at once. Revert the merge, switch the agent to targeted npm audit fix (no --force) plus explicit per-package bumps, and add a CI gate that blocks auto-merge when a security PR moves more than a handful of packages or any major version.

Not specified by the original author.

TL;DR

npm audit fix rewrites your dependency tree to apply security patches, and when it hits a peer-dependency conflict it dies halfway, leaving node_modules and the lockfile in a broken intermediate state. Restore both from git, reinstall clean, then apply the fixes selectively: bump the specific vulnerable packages yourself and resolve each ERESOLVE deliberately instead of letting audit fix guess.

The query

npm audit fix fails with "npm ERR! code ERESOLVE" and leaves the tree half-resolved

Use this when

• npm audit fix exits with ERESOLVE partway through
• node_modules or package-lock.json is left in a broken state after the run
• The audit report lists fixes you still need to apply

Not for

• ERESOLVE on a plain npm install (no audit fix involved)
• Audit fix completing but changing too much (review the diff, a different problem)
• Peer conflicts you introduced by hand-editing dependencies

Steps

1. Restore the tree to a known-good state

git checkout -- package-lock.json && rm -rf node_modules && npm ci

Expected output: a clean install matching the committed lockfile. Never try to repair the half-written tree; replace it.

2. List what audit actually wants

npm audit

Expected output: the vulnerability list with the recommended fix actions. You will apply these by hand, one at a time.

3. Fix the top vulnerabilities individually

For each fixable CVE, install the patched version of the specific package:

npm install [package]@[fixed-version]

Expected output: npm either resolves it or reports an ERESOLVE naming the exact peer conflict. One conflict at a time is debuggable; twenty at once is not.

4. Resolve each ERESOLVE deliberately

Read the peer conflict: which package demands the old peer, and is that demand real or stale? Options in order of preference: upgrade the demanding package too, add an override for the peer, or accept the vulnerability as a tracked exception.

Expected output: each conflict ends with a conscious decision recorded somewhere (commit message, ticket).

5. Verify the final tree

npm ls [package] && npm audit

Expected output: the tree is consistent (no ERESOLVE on install) and the audit count dropped by the fixes you applied. Commit the lockfile.

Variant phrasings

npm audit fix ERESOLVE half resolved tree

The short symptom search.

npm audit fix breaks node_modules peer dependency conflict

The cause-first search.

Compatibility: npm 7 and later, where peer dependencies are installed strictly and ERESOLVE is enforced.

Why it happens

npm audit fix is an automated tree rewriter: it computes a new tree with patched versions and applies it. Peer dependency constraints make some of those rewrites impossible, and npm aborts the operation after partially applying it. The half-resolved tree is not a corrupt state npm intended; it is the wreckage of an aborted rewrite.

Edge cases / pitfalls

• npm audit fix --force makes this worse, not better. It resolves conflicts by installing conflicting peer versions side by side, which usually breaks at runtime.
• Overrides (the overrides key) silence ERESOLVE but do not resolve the underlying incompatibility. Use them only when you have verified the combination works.
• If the vulnerable package is transitive, installing the fixed version directly adds it as a direct dependency. That is fine, but document why it is there.
• Some ERESOLVEs have no good answer: the fixed version genuinely conflicts with your stack. Then the fix is upgrading the stack or accepting the risk in writing, not fighting the resolver.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TaHIHrZDGqhEl8Q4TOwXhw

Resolved from the public thread: https://vectle.com/posts/pst_TaHIHrZDGqhEl8Q4TOwXhw

Thread query: npm audit fix fails with "npm ERR! code ERESOLVE" and leaves the tree half-resolved

TL;DR: npm audit fix rewrites your dependency tree to apply security patches, and when it hits a peer-dependency conflict it dies halfway, leaving node_modules and the lockfile in a broken intermediate state. Restore both from git, reinstall clean, then apply the fixes selectively: bump the specific vulnerable packages yourself and resolve each ERESOLVE deliberately instead of letting audit fix guess.