Do npm overrides work inside a workspace package.json?

No. npm reads overrides only from the root package.json of the project. Overrides written in a workspace's package.json, or in any installed dependency, are not considered when npm resolves the tree. To force a patched version of a transitive package across a monorepo, put the override in the root file.

What the docs say

The npm package.json documentation says overrides are for making specific changes to dependencies of your dependencies: replacing a version with a known security issue, replacing a dependency with a fork, or making sure the same version is used everywhere. It then states that overrides are only considered in the root package.json, and that overrides in installed dependencies, including workspaces, are not considered in tree resolution. Published packages that want a fixed result should pin dependencies or use bundleDependencies.

{
  "name": "my-monorepo",
  "workspaces": ["packages/*"],
  "overrides": {
    "vulnerable-lib": "^1.4.2"
  }
}

An override value can be any specifier npm accepts for dependencies: an exact version, a semver range, a dist-tag, or a replacement such as an npm: alias, a file: path or a Git URL. A range is a good way to enforce a minimum patched release without freezing the exact version.

Why the workspace rule trips people

In a monorepo each workspace has its own package.json, so it feels natural to put the override next to the code that needs it. npm resolves one tree for the whole project from the root, so the override has to live there. A workspace override produces no error. It just does nothing, and the vulnerable version stays.

The last row is covered in npm overrides in a library.

A safe procedure

1. Identify the vulnerable package and the path that brings it in with npm explain. See npm explain.
2. Add the override to the root package.json with a range that includes the fixed version.
3. Reinstall and confirm: run npm ls on the package and check every copy is the patched one.
4. Run tests across all workspaces. A forced version can break a package that expected the old API.
5. Add a note in the pull request: which advisory, which package, and when to remove the override once upstream updates.
6. Re-check periodically, because overrides tend to outlive their reason. Our guide to pinning a transitive dependency with overrides has more detail.

Common errors

If an override conflicts with a direct dependency of the same name, npm reports an error rather than choosing. Fix by aligning the direct dependency's range with the override. See EOVERRIDE.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how a finding with an available fix is presented.

Where Safeguard fits

Safeguard's dependency scanning flags vulnerable transitive packages, and autonomous remediation can propose fix pull requests. It is off by default, and every category starts on Manual, so you approve before anything changes. A free scan is at https://gold.safeguard.sh/scan.

Quick check

Sources

• package.json documentation
• npm workspaces documentation

Last reviewed: 19 October 2026.