An overrides entry in your library's package.json does nothing for people who install your library. The npm docs say overrides are only considered in the root package.json of a project, and overrides in installed packages are ignored. To protect users, raise your dependency range.
What overrides are for
The npm documentation describes overrides as a way to change dependencies of your dependencies, such as forcing a patched version or swapping in a fork. For example, you can pin foo to a version everywhere in the tree.
That is a tool for the owner of an application. If you run a web app and a transitive package has an advisory, an override in your app's package.json can force the patched version while you wait for the middle package to update.
Why it fails for a library
Your library is not the root when someone installs it. Their project is the root. The npm page is explicit: "Overrides are only considered in the root package.json file for a project." So your override works in your own repository during development and CI, which can make it look like a fix, but it disappears from the tree of anyone who depends on you.
This is a common trap. Tests pass, the scanner on your repository goes quiet, and users still resolve the vulnerable version.
What to do in a library
- Find the chain. Which of your direct dependencies pulls in the vulnerable package?
- Check for a fixed release of that direct dependency. If one exists, raise your range to it, and the vulnerable transitive version leaves your users' trees at the next install.
- If none exists, ask upstream. Open an issue or pull request against the middle package asking for a bump.
- If your code does not reach the flaw, say so. A short note in your security policy or an advisory comment can save users from filing reports (see the related post on advisories for vulnerable dependencies).
- As a last resort, replace or vendor the dependency. This has maintenance costs, so decide on purpose.
Keep the override for yourself
You can still use an override in your own repository so your CI tree is clean while you wait. Leave a comment explaining it, link the upstream issue, and remove it once upstream ships:
{
"overrides": {
"vulnerable-package": "2.3.1"
}
}
Note in the release notes that the fix is local, so users know to add their own override if they are affected.
Tell users what to do
Users who are affected can add the override in their own root package.json. A line in your README or release notes with the package name and safe version helps them. Phrase it as a temporary workaround.
Apps versus libraries at a glance
| Application | Library | |
|---|---|---|
Does overrides take effect | Yes, it is the root | Only in your own repo |
| Best fix | Override or upgrade | Raise the range on the direct dependency |
| Who is protected | You | Your users, once ranges move |
Quick check
Can I ship a library with overrides so users get the patched version?
No. npm ignores overrides in installed packages.
Is an override useful in my library's repository at all?
Yes, as a temporary measure for your own CI and development tree. Document it and remove it when upstream is fixed.
Safeguard's dependency scanning shows which direct dependency brings in a vulnerable transitive package, which is the first step above. Try the free scan.
Sources
- npm docs, package.json overrides: https://docs.npmjs.com/cli/v10/configuring-npm/package-json
Last reviewed: 19 October 2026.