Yes, when teams share a workspace root, shared lockfile or parent build file, a version override there can change what every team builds. When teams have separate repositories and roots, an override stays inside its own project. Knowing where the boundary lies is how you avoid surprises.
Where the boundary is
Package managers draw the line at the root. npm documents that overrides are only considered in the root package.json, so overrides inside workspaces or installed dependencies do not count. Yarn says the resolutions field can only be set at the root of the project and warns when it is used in another workspace. Cargo reads patch settings only from the manifest at the workspace root.
Two things follow.
- If you control the root, you can change what every member builds.
- If you do not control the root, your own override file may be silently ignored.
pnpm adds a nuance worth checking in its documentation: settings that shape resolution, including overrides, take effect per project only where each project has its own lockfile. On a workspace that uses the default shared lockfile, there is one resolution for every project, and pnpm reports which entries it ignored. Confirm the behavior for your version before relying on it.
Three common surprises
| Surprise | What happened | Prevention |
|---|---|---|
| A fix that did not apply | A team added an override in a workspace package, but only the root counts | Document which file is authoritative |
| A change everyone felt | The platform team added a root override and several services changed behavior | Announce root changes and require owner review |
| A library override that never reached users | A published library carried an override, but consumers' roots ignore it | Fix at the application root, or release a new library version |
Reduce surprises
Make the root protected. Use CODEOWNERS and branch protection so that edits to root manifests and lockfiles need review from the owning team, and list affected teams as co-owners where it makes sense.
Show the diff of the resolved tree. A change in the resolved dependency list is more informative than a change in the manifest. Ask CI to publish a short summary of added, removed and changed packages for each pull request.
Announce root changes. A short note in the team channel with the package, old and new versions, reason and rollback plan costs two minutes and prevents hours of debugging.
Test where it counts. Run each affected team's tests against the proposed change, or at least a representative subset, before merging.
Separate repositories are not a full shield
Even with separate repos, teams share base images, internal libraries and CI templates. An upstream change in an internal library can flow into all of them. Treat internal libraries as products with release notes and a deprecation schedule.
Try it yourself
Click through it at your own pace, or open it full screen. Look for packages that show up under more than one parent, since those are where a root override reaches furthest.
Quick check
Why did my override in a workspace package not work?
In npm and Yarn the override is read from the root manifest only. Move it to the root, and check the tool documentation for your version.
Should every team be able to edit the root?
Usually not without review. Give the root manifest and lockfile named owners and require their approval.
Sources
- npm package.json: overrides
- Yarn manifest: resolutions
- Cargo: overriding dependencies
- pnpm settings
- About code owners (GitHub Docs)
Last reviewed: 19 October 2026.
