Yes, delete the old lockfile in the same pull request that adds the new one, once you have verified that the versions match. A second lockfile that nobody updates goes stale, may still be read by scanners and old scripts, and can make the repository look as if it has vulnerable versions that no longer ship.
What goes wrong with two lockfiles
Several things, none dramatic, all annoying:
- A scanner reads both files and reports findings from the stale one, so the team chases advisories for versions that are not installed.
- A Dockerfile or script still runs the old tool, which installs from the old lockfile and ships something different from what CI tested.
- Someone updates the wrong file in a fix, and the real lockfile never changes.
- Reviewers cannot tell which file is the source of truth.
The npm documentation shows how tools can prefer one file over another: when both package-lock.json and npm-shrinkwrap.json are present in a project root, npm-shrinkwrap.json takes precedence and package-lock.json is ignored. Precedence rules like that exist because ambiguity happens, and they differ per tool.
The order of operations
- Convert the lockfile with the new tool's import path where one exists. For pnpm that is the import command; for uv it is adding requirements with constraints.
- Verify versions with the method in how to verify resolved versions after switching package managers.
- Install from the new lockfile in a clean environment and run the tests.
- Delete the old lockfile and the old tool's config in the same pull request.
- Update CI, Dockerfiles and docs to the new commands.
- Search the repository for the old file name to catch stragglers.
Keep a recovery path without keeping the file
You do not need the old lockfile in the working tree to be able to roll back. Version control keeps it. Tag the last commit that used the old tooling so that you can find it quickly. See a rollback plan for a package manager migration.
Exceptions
| Case | What to do |
|---|---|
| Library published to a registry | Check what the new tool publishes and whether consumers need a lockfile |
| Transition period with both toolchains in CI | Keep both, time boxed, with a ticket to remove one |
| A published shrinkwrap in npm | Review whether you intend to publish it, since the npm docs say it is not recommended except for CLI tools and similar |
For the commit question itself, see commit lockfile for apps and libraries by ecosystem.
Try it yourself
Click through it at your own pace, or open it full screen. Check that the inventory is built from one source, which is what a single lockfile gives you.
Safeguard's dependency scanning and SBOM generation work from the repository. A free scan is at gold.safeguard.sh/scan.
Quick check
Is it risky to remove the old lockfile?
Not if the versions are verified and the history is tagged. Version control keeps the file.
Why not keep both for safety?
They drift, and scanners may read the stale one. A clear single source is safer.
Sources
Last reviewed: 19 October 2026.
