The root manifest owner, usually a platform or build team, should approve overrides, with the affected teams reviewing. In npm and Yarn, overrides and resolutions in a workspace package are ignored, so one root file changes the whole repository. A shared lever needs a shared review.
Why the root file matters
The npm documentation says only the root package.json is considered for overrides. Overrides in installed dependencies, including workspaces, are ignored during resolution. Yarn's documentation says the same for resolutions: set them in a workspace and you get a warning and no effect.
So a team that wants to force a patched version in its own app cannot do it in its own folder. It has to edit the root file, which every other team also depends on.
What can go wrong
An override at the root can be broad. The npm syntax allows a global form that forces a package to a version everywhere in the tree, or a scoped form that applies only under a named parent. A global override fixes the advisory for everyone and may also break a team that was relying on the older behavior.
That is the dispute in miniature. The security-minded team wants the fix now. The team with a fragile build wants it scoped or delayed.
A practical approval model
Keep it light, and keep it in the pull request.
- Author opens a PR editing the root manifest and states the advisory or reason.
- Scope check. The reviewer confirms the narrowest scope that works. Prefer a parent scoped override over a global one when only one subtree is affected.
- Affected teams are tagged automatically. Use ownership rules so changes to the root file request review from each team with a workspace that resolves the package. Run the dependency tree command to find them.
- Platform owner approves and merges.
- Register the override with an owner and a review date.
If your repository host supports code ownership files, point the root manifest and lockfile at the platform team plus a security reviewer. That alone prevents silent edits.
Evidence the reviewer needs
Ask for three things in the PR description.
- The advisory identifier or reason for the change.
- The output of the tree command showing which workspaces resolve the package.
- A passing test run for each of those workspaces.
A reviewer who has these can approve in minutes. A reviewer without them will, reasonably, say no.
Decide what is not allowed
Write down two rules to save arguments later.
- No override for a direct dependency with a different version than its declared range. npm raises an error in that case unless the specs match or a dollar reference is used.
- No permanent overrides. Every entry carries a date to retry removal once the upstream fix lands.
Quick check
Can one team set an override just for its workspace?
In npm and Yarn, no. Workspace level overrides and resolutions are ignored, so the change must go in the root manifest.
Should every override need a security review?
Overrides that change a package version for the whole repository deserve one. A narrowly scoped override with passing tests can use a lighter path.
Sources
Last reviewed: 19 October 2026.
