No. According to the npm documentation, overrides are only considered in the root package.json of a project. If your design system sets one, it helps your own repo and does nothing for the apps that install the published package. To fix consumers, change your declared ranges or have each app add its own override.
Why the confusion happens
In your design system repo, you are the root project. You add an override for a vulnerable transitive package, run your scan, and the finding clears. It feels like the problem is solved for everyone.
But when an app installs your library, the app is the root. The npm page says overrides in installed dependencies, including workspaces, are not considered during resolution. It adds that published packages can dictate resolutions by pinning dependencies or by shipping a shrinkwrap file. Yarn documents the same boundary for its resolutions field, which it says is only honoured at the project root. Check your package manager's page before you assume.
What each approach reaches
| Action in the design system repo | Fixes your repo | Fixes consuming apps |
|---|---|---|
| Add an override or resolution | Yes | No |
| Raise the declared range floor on a direct dependency | Yes | Yes, once the app updates its lockfile |
| Update the direct dependency that pulls the vulnerable package | Yes | Yes, after the app takes your new release |
| Ship a shrinkwrap file | Yes | Yes, but it freezes the app's choices |
A path that works
- Find the dependency in your tree that brings in the vulnerable version, using the explain command of your package manager.
- If a newer release of that direct dependency fixes it, update it in the library and publish a patch release.
- If no release exists yet, keep a temporary override in your repo so your CI is clean, and write down an expiry date. See temporary overrides need an expiry.
- Publish a short note telling app teams which version of your library to take, and what they can do in the meantime. An app can add its own override in its root file.
- Check adoption afterwards by scanning app lockfiles, not the library repo.
Why a shrinkwrap is usually the wrong tool
It can force a fix, but it also stops an app from receiving later patches to the same package through normal range resolution. For a UI library installed in dozens of apps, that trades one problem for a slower one. Prefer changing ranges and releasing patches.
Keep the owner clear
An override in a library repo creates a quiet mismatch: your dashboard says fixed, the apps say vulnerable. Name an owner for the follow up, the same way you would for any internal shared package. The pattern is described in who fixes a vulnerable internal shared library. For the mechanics of the root override itself, see npm overrides: how to pin a transitive dependency.
Safeguard can scan every app's lockfile and show which ones still resolve the vulnerable version after your library release, and autonomous remediation can open fix pull requests for you to review (off by default, every category set to Manual). A free scan is available at gold.safeguard.sh/scan.
Quick check
Do pnpm and Yarn behave the same way as npm here?
Yarn's documentation says its resolutions field is honoured at the project root and warns in workspaces. Check the pnpm documentation for its own rule before relying on it.
Can my library ship a fix without the app doing anything?
Not reliably. The app has to update its lockfile or take your new release, which is why adoption tracking matters.
Sources
Last reviewed: 19 October 2026.
