Let the package manager regenerate the lockfile instead of editing conflict markers by hand, then review the resulting diff. Lockfiles are machine written, and hand edits easily produce a tree that no real install would create. The review step matters, because regeneration can move versions you did not mean to change.
What the documentation says
The pnpm documentation on git workflows states that pnpm can automatically resolve merge conflicts in pnpm-lock.yaml: if you have conflicts, run pnpm install and commit the changes. It adds a warning. Review the changes before staging the commit, because pnpm cannot be guaranteed to choose the correct head. It builds with the most updated of the lockfiles, which is ideal in most cases.
The Yarn 1 documentation points the same way from a different angle. It says the yarn.lock file is auto generated and should be handled entirely by Yarn, and that you should not edit the file directly, since it is easy to break something.
Other package managers have their own commands, so check yours before applying this advice. The principle is common: the tool that wrote the file should rewrite it.
Why a security reviewer cares
A lockfile conflict is a moment when versions can shift quietly. Two branches each changed the tree. Regenerating combines them, and the result may differ from both. A transitive dependency might move to a newer release because the conflict forced a re-resolution, or a version that one branch had deliberately pinned to avoid a vulnerable release might be lost.
That second case is the dangerous one. If a branch fixed a vulnerable transitive version and the merge drops the fix, the application silently regresses. No test will fail, since the code still works.
A safe procedure
- Merge or rebase and accept the conflict.
- Take one side of the lockfile, usually the target branch's version, so the file is valid.
- Run the package manager's install command to regenerate it against the merged manifests.
- Diff the result against the target branch's lockfile.
- For every changed version, ask whether it is intended. Pay particular attention to downgrades.
- Re-run your dependency scan and compare the findings with the target branch.
- Commit only when the findings are no worse than before.
| Diff pattern | What to do |
|---|---|
| Only the packages you changed moved | Accept |
| Unrelated transitive versions moved | Look for why, accept only if explainable |
| A version went down | Check whether a fix was lost |
| A new package appeared | Confirm which manifest asked for it |
Make it hard to miss
A pull request gate that compares scan results before and after, and flags new findings, catches a lost fix automatically. Conflict resolution commits are often waved through because they look mechanical, which is exactly why a check that does not rely on a person noticing is useful.
Try it yourself
The demo shows a pull request gate stopping a change that adds a risk. Click through it and think about how the same check would treat a lockfile that has just been regenerated after a conflict.
Click through it at your own pace, or open it full screen.
Safeguard offers policies and gates for pull requests, and its dependency scanning can be tried through the free scan.
Quick check
Is it ever fine to edit a lockfile by hand?
The Yarn docs advise against it. Prefer the tool's command, then review the diff.
Why review after pnpm resolves the conflict itself?
The pnpm docs warn that it cannot guarantee it picks the correct head, so changes should be checked before committing.
Sources
Last reviewed: 19 October 2026.
