Myth. An override forces a version in your own build, but the parent package still asks for the old one. It reaches only the project that sets it, and it can hide the problem from the people who could fix it upstream. Treat it as a bridge with an end date.
Myth 1: the override fixes the problem for everyone
Fact. It fixes your build. npm's documentation says only the root package.json is considered, and overrides in installed dependencies are ignored. Published packages control their own resolutions by pinning dependencies or shipping a shrinkwrap file.
So if your library sets an override, your consumers do not get it. Go behaves similarly: replace and exclude apply only in the main module. A library team that relies on an override has fixed their own tests, not anyone else's build.
Myth 2: once overridden, we can forget it
Fact. An override drifts. The parent may later require a range that conflicts with your forced version. The forced version may itself get an advisory. The parent may release a fix, making your override redundant, and you will not notice unless you look.
Put a review date on every override. When it comes up, check whether the parent now asks for a fixed version. If so, remove the override and let normal resolution do the job.
Myth 3: an override is risk free because the version number is higher
Fact. Higher is not the same as compatible. The parent was tested with the version it asked for. The npm audit documentation warns about SemVer-major changes forced outside stated ranges and advises against forcing without knowing what changes. Run tests for every service that resolves the package.
Quick comparison
| Claim | Reality | What to do |
|---|---|---|
| Fixes everyone | Fixes the project that sets it | Raise the issue upstream |
| Set and forget | Needs a review date | Calendar the check |
| Safe because newer | Compatibility is unverified | Test affected services |
| Hidden is handled | Upstream may never learn | File an issue or PR |
What a healthy override lifecycle looks like
- Apply the override with a reason, owner, and review date.
- Open an issue or pull request with the parent project asking for an updated range.
- At the review date, check the parent's latest release.
- If it asks for a fixed version, remove the override and confirm the resolved version stays fixed.
- If not, extend the date once, with a note, and escalate the upstream request.
An override that survives three reviews deserves a decision: replace the parent, fork it, or accept the exception formally.
Why teams get this wrong
Overrides feel like a finished fix because the scanner turns green. A green scanner is a result, not a state of the world. The dependency tree is still pointing at an old requirement, and your build holds it up with one line.
Quick check
Do my library's overrides protect people who install it?
No. In npm only the root project's overrides apply, and in Go replace applies only in the main module.
How do I know when to remove an override?
When the parent package's latest release asks for a fixed version of the dependency. Check at the review date.
Sources
Last reviewed: 19 October 2026.
