For a peer dependency, your user's project decides the version, so your job is to widen your range to allow the fix and tell users. For an optional dependency, you ship it only if installable and must handle its absence. Plain dependencies are the ones you own.
How npm defines each type
From the npm package.json documentation:
| Field | Meaning | Installed for users? |
|---|---|---|
dependencies | Packages your code needs | Yes |
devDependencies | Development tools such as test and docs frameworks | Not meant for consumers |
peerDependencies | Compatibility with a host tool or library, usually for plugins, without requiring it directly | Since npm v7, installed by default |
peerDependenciesMeta | Marks a peer dependency as optional | Not installed automatically if optional |
optionalDependencies | Useful but not required, installation failure does not stop the install | Skipped with --omit=optional |
An entry in optionalDependencies overrides a same-named entry in dependencies, so list it in only one place. The docs also say your program must handle the dependency being absent.
Who decides the version
Dependencies. Your range, resolved by the user's package manager. You own the floor.
Peer dependencies. The host project usually has the package already and chooses its version. Your range declares what you are compatible with. If an advisory affects the peer, the user needs to upgrade the package in their own project. Your role is to make sure your range allows the patched version, and to say so.
Optional dependencies. They are installed when possible. A vulnerability in one affects users who got it. Check whether your feature code is the thing that calls it.
What to do for a peer dependency advisory
- Check your range. If it stops users from adopting the fixed major version, widen it.
- Test against the fixed version in CI.
- Release a version that allows the fix, and note it.
- Tell users plainly that the upgrade is on their side, with the command.
Avoid declaring a peer range that excludes the patched version for months. That forces users to choose between your plugin and a fix.
What to do for an optional dependency advisory
- Decide whether your usage reaches the vulnerable code.
- If it does, raise the floor for that optional package and release.
- If not, document that and still consider bumping.
- Make sure the code path when it is missing still works, because users may omit it.
The dev dependency case
Dev dependencies are lower priority for published libraries because users do not install them, but they still run in your CI. See the related post on dev dependency alerts for a triage order.
Overrides do not help here
An overrides entry only applies in the root project, so it cannot fix a peer for your users. The npm docs say overrides in installed packages are ignored.
Quick check
Do peer dependencies get installed automatically?
Since npm v7, yes by default, unless they are marked optional in peerDependenciesMeta.
Can a library fix a peer dependency flaw for its users?
Only indirectly, by allowing the patched version in its range. The user's project controls the installed version.
Safeguard's dependency scanning separates direct, transitive and optional components so you can see where a finding lives. Try the free scan.
Sources
- npm docs, package.json: https://docs.npmjs.com/cli/v10/configuring-npm/package-json
Last reviewed: 19 October 2026.
