A lockfile only fix moves an installed version inside the range your manifest already allows. A manifest change edits the range itself. The first is usually lower risk and easier to revert, the second changes what future installs may pick. Review both by reading the resolved package list, not the raw diff.
What each change means
Your manifest, such as package.json, states which versions you accept. Your lockfile records the exact versions that were resolved. If the manifest says a package is acceptable in a compatible range and the lockfile pins an older release, a fix can simply re-resolve to a newer release in that range. Nothing in the manifest changes.
When no version inside the range contains the fix, the manifest must change, for example to raise the minimum version. That is a decision about which versions you accept from now on, so it deserves a closer look.
Reviewing a lockfile only change
- List the packages that moved. Ignore line order. Make a list of name, old version, new version.
- Check the target is expected. The vulnerable package should be in the list at a fixed version.
- Look for extras. Other packages that moved are transitive updates. Check each for jumps beyond patch level.
- Check integrity fields and sources. Registry URLs should match your usual registry. A changed source for an existing package deserves a question.
- Run a frozen install in CI.
npm ciinstalls from the lockfile, never writes to it, and exits with an error if the lockfile andpackage.jsondisagree.
Reviewing a manifest change
Everything above, plus:
- Why the new minimum? It should be the earliest fixing release.
- Does it narrow compatibility? Raising a minimum can conflict with other packages that need an older one.
- Is it a library you publish? If your package is consumed by others, raising a range forces them to move too. For applications this matters less.
- Is it an exact pin? Pinning is stricter than a range. It buys reproducibility and costs you automatic patch pickup.
Peer dependencies and conflicts
If the resolver reports a peer dependency conflict, stop. Forcing the install may produce a tree that works in CI and fails in production. Resolve the conflict deliberately, possibly with a scoped override.
Monorepos and workspaces
With a single root lockfile, one fix may move packages used by several services. Ask which workspaces consume the changed package, and who owns them. CODEOWNERS can route the PR, see CODEOWNERS for bot opened pull requests.
Quick check
Why prefer a lockfile only fix when possible?
It changes the installed version without changing your declared acceptance range, so it is smaller in scope and simple to revert.
What does npm ci do if the lockfile is out of sync?
It exits with an error instead of updating the lockfile, which makes it useful as a CI guard.
Safeguard dependency scanning and SBOM generation read your lockfiles, so findings point at the exact resolved version rather than the declared range.
Sources
Last reviewed: 19 October 2026.
