Inventory every version of each shared dependency across the repos you are merging, choose one patched target per package, and upgrade in small steps with tests between. Do it by risk: security-relevant and widely used packages first. Where you cannot align yet, record the exception with an owner and a date.
Why this comes up
Ten repos built over years rarely agree. One service pins an old HTTP client, another uses a major version newer. In a workspace they share one install tree or one lockfile, so differences become visible, and a vulnerable old version may now sit beside a patched one. Our post on counting one vulnerability across many monorepo packages covers how to report it.
Steps
- Inventory. List each dependency and each version in use, with the repo or directory. A script over lockfiles is enough to start.
- Sort by risk. Put packages with known vulnerabilities, packages that handle untrusted input, and packages used in many places at the top.
- Choose targets. For each, pick the version that fixes known issues and is supported by the maintainers. Check release notes for breaking changes.
- Upgrade in slices. One package, one pull request, with the services that use it tested together.
- Use one mechanism for central versions. Some package managers offer a way to declare a version once for the workspace. See pnpm catalogs for one approach.
- Track exceptions. Where a service must stay on an old version, write down the reason, the owner, and a review date.
Keep internal packages explicit
When internal libraries were published versions in separate repos, they become local packages in the workspace. pnpm's documentation explains the risk: if a dependency range matches a package in the workspace it may be linked, but if it does not match, the version is installed from the registry instead, and the docs call this behavior uncertain. The workspace: protocol makes pnpm refuse to resolve to anything other than a local workspace package, so a mismatch fails the install instead of silently pulling from the registry. See pnpm workspace protocol: fail instead of registry fallback.
Do not hide the old version
Hoisting and deduplication can make an old version invisible in a quick check. Use your lockfile and SBOM as the source of truth, not what a service appears to import. For a one-time clean-up of a version, see write an upgrade runbook for a vulnerable dependency.
Measure progress
Track the count of distinct versions per top-risk package. It should fall steadily. Safeguard's autonomous remediation can open fix pull requests for vulnerable dependencies (it is off by default, with every category set to Manual), and its SBOM and dependency scanning supply the inventory.
A worked order of operations
Suppose three services use an HTTP client at three different major versions. Start with the version that has a known vulnerability, upgrade that service, and run its tests. Then move the second service to the same target. Leave the third on its version if the upgrade needs a rewrite, and record why. At the end of the week you have one fewer vulnerable version in production and a dated exception for the rest, which is a more honest state than a promise to align everything later.
Who decides
Pick a single owner for each shared dependency. Without one, every team waits for another team to upgrade first. The owner can be the team that uses it most, or the platform team. CODEOWNERS on the lockfile or the central version file helps route those pull requests.
Quick check
Should I align every dependency before the cutover?
No. Align the risky and widely shared ones first, and track the rest as dated exceptions.
Why use the workspace protocol for internal packages?
It makes an install fail rather than fall back to a registry package with the same name.
Sources
Last reviewed: 19 October 2026.
