EOVERRIDE means you set an override for a package you also list as a direct dependency, and the two specs differ. npm allows it only when they match exactly. The fix is to write the override as a dollar reference to your own dependency entry, or to change the dependency itself.
What the rule says
The npm documentation on package.json describes overrides as a way to make specific changes to dependencies of your dependencies, for example replacing a version that has a known security issue, replacing a dependency with a fork, or making sure the same version of a package is used everywhere. One rule applies when the package is also yours: you may not set an override for a package you directly depend on unless both the dependency and the override share the exact same spec.
If they differ, npm throws an EOVERRIDE error. A typical case is a security push where you add an override for a package that, it turns out, you also require directly with a looser range.
Three ways out
| Fix | When to use it |
|---|---|
| Change the direct dependency to the fixed version | You import the package yourself |
| Make the override match the direct spec exactly | The direct spec already admits the fix |
| Use a dollar reference in the override | You want one source of truth for the version |
The dollar form is the documented preferred form. You define the override as a reference to the spec of a direct dependency by prefixing the package name with a dollar sign. The docs show that the referenced package does not need to match the overridden one, so one direct dependency can drive the version of another package as well.
{
"dependencies": { "foo": "^1.2.0" },
"overrides": { "foo": "$foo" }
}
Steps
- Read the error. It names the package and the conflicting specs.
- Ask whether you really need an override. If you depend on the package directly, simply raising your own requirement is clearer.
- If a nested package also pulls the same package, keep the direct requirement at the fixed version and use the reference form for the override.
- Reinstall so the lock file updates.
- Check the resolved tree for the package. Every path should now show the fixed version.
- Run your tests.
Other rules worth remembering
Overrides are only considered in the root package.json of a project. The docs state that overrides in installed dependencies, including workspaces, are not considered in dependency tree resolution. That has two consequences. A library you publish cannot force versions on its consumers through overrides. And in a monorepo, put the override in the root manifest.
Keys can be nested, so you can scope an override to a package that is a child of another, and the key can include a version or range. Scope narrowly. A broad override that covers every version of a package can hide the next problem. For the basic mechanics, see the guide on npm overrides to pin a transitive dependency.
Try it yourself
Click through it at your own pace, or open it full screen. Find a package that is both direct and transitive, which is the case that triggers this error.
Where Safeguard fits
Safeguard scans dependencies, runs reachability analysis to show which findings your code can actually reach, and can open fix pull requests through autonomous remediation. That last feature is off by default and every category starts on Manual, so a person approves each change. You can try a free scan on a repository first.
Quick check
Can a published library use overrides to force versions on its users?
No. The npm docs say overrides in installed dependencies are not considered. Only the root project's overrides apply.
What is the dollar reference form?
An override value that points at a direct dependency's spec, so both use one version source.
Sources
Last reviewed: 19 October 2026.
