Export the resolved dependency list before the migration and again after, then diff the two. Moving to workspaces or a new package manager regenerates the lockfile, and transitive packages can resolve to different versions without anyone choosing that. Review every added, removed, upgraded or downgraded package, with extra attention to downgrades and new install scripts.
Why a diff, not a glance
A lockfile records exact versions. When a migration deletes and regenerates it, the resolver starts again from your declared ranges, and anything not pinned can land on a different version than yesterday. Most shifts are harmless. A few are not: a downgrade to a version with a known flaw, a new package that was not there before, or a package that now runs a build script.
pnpm's documentation describes a related behavior inside workspaces: when a declared range does not match a local package, the version is installed from the registry, and it calls this behavior uncertain. A migration that turns private libraries into workspace packages is where that bites.
Steps
- Freeze a baseline. On the last good commit, install from the lockfile and export the full resolved tree: name, version and, if you can, integrity hash. A software bill of materials in CycloneDX or SPDX works well, as does a script over the package manager's list output.
- Migrate on a branch. Convert the manifests, regenerate the lockfile.
- Export again the same way.
- Diff by package name and version. Sort the output into groups: added, removed, upgraded, downgraded, unchanged.
- Review the groups in the order below.
- Run the tests and a scan against the new tree.
- Keep both exports with the migration pull request as evidence.
What to review first
| Group | Why it matters | Action |
|---|---|---|
| Downgrades | May reintroduce fixed vulnerabilities | Pin to the old version or justify |
| Added packages | New code in your build | Check purpose and maintainer |
| Removed packages | May hide a missing feature | Confirm intended |
| Install scripts | Run code at install | Review as build scripts |
| Registry versions of internal names | Possible wrong source | Use the workspace protocol |
Check integrity and source
Compare where each package comes from as well as which version. A package with an internal name resolved from the public registry is a red flag, covered further in unscoped internal package names and dependency confusion.
Plan the way back
If the diff is large or messy, you want an exit. See a rollback plan for a package manager migration. The same discipline applies to scanner changes, discussed in scanner migration checklist.
Automate the check
Run the diff in CI on the migration branch. Safeguard's SBOM and dependency scanning produce the component inventory for each side, and its gates can flag pull requests that add vulnerable packages.
Quick check
Is a regenerated lockfile a security event?
Not automatically, but it is a change to everything you ship. Treat it as a reviewed diff.
What should I look at first in the diff?
Downgrades and newly added packages, then any package with an install script.
Sources
Last reviewed: 19 October 2026.
