Why use “overrides” in package.json | The Silent Fixer Your Node/Nest Project Needs

In this post, you’ll learn what package.json overrides are, why they exist, when to use them (and when not to), and how to write them correctly with real examples you can copy today.

You’ve stared at a cryptic vulnerability warning for the third day in a row. The fix exists, but it’s buried inside someone else’s package, and you can’t touch it. Or can you?

You run npm audit. It yells at you. There's a known security vulnerability hiding inside a deeply nested dependency — something like lodash@4.17.4 buried inside a package you didn't even choose directly. You can't update it yourself. The parent package hasn't released a fix yet. And every CI build is now flagged.

Sound familiar? This is one of the most frustrating situations in modern JavaScript development. And this is exactly where package.json overrides walk in and quietly save the day.

What Are package.json Overrides, Anyway?

In simple terms, overrides is a field in your package.json That lets you force a specific version of a package — even if that package is a dependency of a dependency (and a dependency of that, and so on).

It was introduced natively in npm v8.3.0 (shipped with Node.js 16+). If you’ve used Yarn before, you might know it as resolutions — same idea, different name.

Think of it like this: you’re renting a furnished apartment (your project), and the furniture came pre-assembled by someone else (your dependencies). One chair has a wobbly leg. You can’t replace the whole furniture set, but with overrides, you can quietly swap that one broken leg without touching anything else.

“overrides lets you be the boss of your dependency tree — even the parts you didn’t write.”

Why Does This Field Even Exist?

JavaScript’s node_modules ecosystem is famously deep. When you install one package, it drags in 5 others. Those 5 bring in 20 more. Before you know it, you have 800 packages for a project that does one thing.

Problems start when:

• Two packages need different versions of the same dependency — and they conflict
• A security vulnerability is found in a nested dependency you don’t control directly
• A package you depend on is slow to update its own outdated internals
• You need to patch a bug in a dependency before the maintainer gets around to fixing it

Before overrides existed in npm, your only options were ugly: fork the package, pin awkward workarounds, or just ship the vulnerability and hope nobody noticed. Not ideal.

How to Use Overrides in package.json

The syntax is clean. Here’s the basic structure:

// package.json
{
  "name": "my-app",
  "version": "1.0.0",
  "dependencies": {
    "some-package": "^2.0.0"
  },
  "overrides": {
    "lodash": "^4.17.21"
  }
}

That’s it. Now every package in your tree that pulls in any version of lodash will be forced to use ^4.17.21. You just patched a vulnerability without touching the package that caused it.

Going Deeper: Scoped Overrides

Sometimes you don’t want a global override — you only want to target a specific package’s dependency. You can do that too:

"overrides": {
  "some-package": {
    "lodash": "^4.17.21"
  }
}

This says: “Only override lodash when it’s inside some-package. Leave everything else alone.” Much more surgical when you need it.

Self-Referencing Your Own Version

There’s also a handy shorthand for when you want a package to always use the same version as what you’ve declared in your top-level dependencies:

"overrides": {
  "lodash": "$lodash"
  // ^ Reads: "use whatever version I declared in dependencies"
}

This keeps things DRY — no duplicating version numbers in two places.

Common Mistakes to Avoid

Overrides are powerful — which means they can also break things quietly if you’re not careful.

Overrides vs. Resolutions: What’s the Difference?

If you’ve worked with Yarn, you already know resolutions — it's Yarn's version of the same concept. Here's a quick comparison so you're not caught off guard:

The semantics are very similar, but the syntax differs slightly. If you’re switching between package managers, double-check which field name your toolchain expects.

Actionable Tips Before You Use Overrides

Tip 01: Always audit first Run npm audit or npm ls <package> before writing an override to understand exactly what's depending on what.

Tip 02: Comment your overrides Add a note above each override explaining why it exists and link to the issue or PR that tracks the real fix.

Tip 03: Set a removal reminder Use a GitHub issue or calendar reminder so you clean up overrides once the upstream package ships the proper fix.

Tip 04: Test, then test again Run unit tests, integration tests — the works. A version change deep in the tree can trigger surprising failures.

Should You Always Use Overrides?

No — and that’s important to say clearly. overrides is a tool for specific situations, not a default workflow.

⚠️ When NOT to Use Overrides Don’t use overrides as a shortcut to avoid updating your own dependencies. If you can update the parent package directly, do that instead. Overrides are for when you’re blocked by someone else’s release cycle — not when you’re avoiding your own maintenance work.

Conclusion

The overrides field in package.json is one of those features that feels small until the day you desperately need it. Security vulnerabilities don’t wait for package maintainers. Version conflicts don’t care about your sprint deadline. Knowing how and when to use overrides gives you a real lever to pull when the dependency tree is working against you.

Use it deliberately. Document it clearly. Test it thoroughly. And remember to clean it up when the real fix arrives upstream.

Because the best override is ultimately the one you don’t need anymore.

Thanks for Reading!

If you found this useful: Clap for the article, it helps others discover it Follow me for more practical guides on analytics, web development, and real-world engineering solutions Leave a comment if you’d like a deep dive into any specific Matomo feature

I regularly share hands-on content about: Information technology, / Web, / Analytics, / NodeJS / Nest.js / React / Next.js, / System design, / real project learnings.