npm overrides: how to force a version of a transitive dependency

The overrides field in your root package.json tells npm to use a specific version of a package wherever it appears in the tree, including as a dependency of your dependencies. Use it when a fix exists but an intermediate package has not picked it up yet, and plan to remove it later.

The basic form

The shorthand pins a package across the whole tree.

{
  "overrides": {
    "foo": "1.0.0"
  }
}

Every copy of foo, however deep, now resolves to 1.0.0.

Scope rules worth knowing

The npm documentation is specific on several points.

• Overrides are only considered in the root package.json of the project. Overrides inside installed dependencies, including workspaces, are ignored during tree resolution.
• Keys can be nested to any length, which limits the override to a package that appears under a given parent.
• A key can include a version or range, so you can target only certain copies.

{
  "overrides": {
    "bar": {
      "foo": "1.0.0"
    },
    "baz@2.0.0": {
      "foo": "2.1.0"
    }
  }
}

In this example, foo is changed only beneath bar, and beneath baz at version 2.0.0.

Direct dependencies and the dollar sign

You may not set an override for a package you depend on directly, unless the override and the dependency declare the same spec. Otherwise npm raises an EOVERRIDE error.

To keep them in sync, a value can reference the direct dependency with a dollar prefix.

{
  "dependencies": {
    "foo": "^1.0.0"
  },
  "overrides": {
    "foo": "$foo"
  }
}

That makes the override follow whatever range the direct dependency declares.

When overrides are a good idea

• A vulnerability is fixed in a newer release of a transitive package, and the parent package has not updated its range.
• You want to collapse two versions of one package into one.

Verifying that it worked

After adding an override, reinstall and look at the tree for the package. Every copy should show the version you set. Then rerun your vulnerability scan, since the point of the exercise is that the advisory no longer matches. If an old copy remains, the override key probably does not match how the package is named or nested.

When to be careful

An override forces a version the parent did not test against. A patch level change is usually low risk. A major change can break the parent in ways that only appear at runtime, so run your tests and exercise the affected code paths.

Keep overrides honest:

• Add a comment in the pull request, or a note in your repository, with the advisory and the date.
• Revisit them when the parent package releases an update. A forgotten override can hold you back for years.
• Check the lockfile diff after adding one, to see what actually moved.

Safeguard's dependency scanning shows which transitive package carries a known issue, and autonomous remediation can propose fix pull requests, which is off by default and manual until you enable it. A free scan is at gold.safeguard.sh/scan. For the full workflow, see how to remediate transitive dependency vulnerabilities.

Quick check

Sources

• package.json overrides, npm Docs

Last reviewed: 19 October 2026.