Skip to main content
Bun supports npm’s "overrides" and Yarn’s "resolutions" in package.json. Both specify a version range for metadependencies, the dependencies of your dependencies.
package.json
By default, Bun installs the latest version of all dependencies and metadependencies, according to the ranges specified in each package’s package.json. Say your project has one dependency, foo, which in turn depends on bar. That makes bar a metadependency of your project.
package.json
When you run bun install, Bun installs the latest version of each package.
tree layout of node_modules
If a security vulnerability is introduced in bar@4.5.6, you may want to pin bar to an older version that doesn’t have it. That’s what "overrides" and "resolutions" are for.

"overrides"

Add bar to the "overrides" field in package.json. Bun defers to the specified version range when determining which version of bar to install, whether it’s a dependency or a metadependency.
package.json
Overrides are only read from the root package.json, not from workspace packages. They apply to peerDependencies as well.

"resolutions"

"resolutions" is Yarn’s alternative to "overrides", with similar syntax. Bun supports it to make migration from Yarn easier.
package.json

Values

A value can be any dependency specifier, not only a version range. npm: swaps a package for a fork, and catalog: (or catalog:<name>) keeps the overridden version in sync with a workspace catalog:
package.json
A value of "$name" reuses the range you declared for name in your own dependencies, so "bar": "$foo" pins bar to whatever range you declared for foo.

Nested overrides

A rule can be scoped to one parent package, so it only applies to that package’s direct dependency. The npm object form, the pnpm > form, and a parent with a version range are all accepted:
package.json
"." inside an object overrides micromatch itself, like a top-level "micromatch" rule. "resolutions" accepts Yarn’s path form. ** is accepted for compatibility, but only the parent’s direct dependency is affected either way:
package.json
When several rules match, the most specific wins: parent-with-version > parent > top-level.

Version-scoped overrides

The key can carry a version selector so the rule only applies to dependents whose declared range overlaps it. This is the form pnpm audit --fix writes:
package.json
The selector is compared with the range each dependent declares, not the resolved version. "semver@<7.5.2" applies to a dependent that declares ^7.3.0 (which could still pick 7.3.x) but not to one that declares ^7.5.2. Dependents using a dist-tag, catalog:, workspace:, git, or URL specifier never match a selector.

Limitations

  • Only one parent level is supported. a>b>c, a/b/c, and deeper object nesting are ignored with a warning.
  • pnpm’s "pkg@" (empty selector) and "-" (remove dependency) forms are not supported and are skipped with a warning.
  • A lockfile containing nested or version-scoped rules is written as lockfileVersion 3, which older versions of Bun cannot read.