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.

```text
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