new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

Bun · Package manager · all subjects

overrides

15 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

overrides apply to peerDependencies

Overrides specified in package.json apply not only to regular dependencies and metadependencies, but also to peerDependencies.

overrides and resolutions define metadependency versions

Bun supports both npm's "overrides" and Yarn's "resolutions" fields in package.json. Both specify version ranges for metadependencies, which are the dependencies of your dependencies. Overrides and resolutions allow you to control which versions of indirect dependencies are installed.

overrides field syntax and placement

The "overrides" field is added to the root package.json as an object where keys are package names and values are version ranges or specifiers. For example: {"overrides": {"bar": "~4.4.0"}}. Bun only reads overrides from the root package.json, not from workspace packages.

resolutions field for Yarn compatibility

The "resolutions" field is Yarn's alternative to "overrides" with similar syntax. Bun supports it to help projects migrate from Yarn. It has the same structure: an object with package names as keys and version specifiers as values.

override values can use npm: catalog: and $name specifiers

Override values can be any dependency specifier, not just version ranges. The "npm:" prefix swaps a package for a fork (e.g., "npm:@myorg/quux@^1.0.0"). The "catalog:" or "catalog:<name>" specifier keeps the overridden version in sync with a workspace catalog. A value of "$name" reuses the version range declared for that package in your own dependencies (e.g., "bar": "$foo").

nested overrides syntax with npm object form

Nested overrides can be scoped to one parent package using an object form. The key "." inside an object overrides the package itself. For example: {"micromatch": {".": "^4.0.5", "picomatch": "^2.3.2"}}.

nested overrides syntax with pnpm > form

Bun accepts pnpm's nested override syntax using the > operator: "micromatch>picomatch": "^2.3.2". This applies the override only to picomatch when it is a direct dependency of micromatch.

nested overrides with parent version range

Nested overrides can include a version range for the parent package, so the rule only applies when the parent matches that range: "micromatch@^4>picomatch": "^2.3.2".

resolutions path form with forward slash

For resolutions, Bun accepts Yarn's path form using forward slashes: "micromatch/picomatch": "^2.3.2". This rule only affects the parent's direct dependency. Bun also accepts ** for compatibility ("**/micromatch/**/picomatch": "^2.3.2"), but it has the same effect as the simpler form.

override specificity precedence

When multiple override rules match, the most specific one wins. The precedence order is: parent-with-version > parent > top-level.

version-scoped overrides apply conditionally

Override keys can include a version selector so the rule only applies to dependents whose declared version range overlaps it. For example: "semver@<7.5.2": "7.5.2". Bun compares the selector with the range each dependent declares, not the resolved version. "semver@<7.5.2" applies to a dependent declaring "^7.3.0" but not to one declaring "^7.5.2". Dependents using dist-tags, "catalog:", "workspace:", git, or URL specifiers never match a version selector.

version-scoped override syntax examples

Version-scoped overrides can be top-level ("semver@<7.5.2": "7.5.2"), parent-scoped ("webpack>terser@4": "4.8.1"), or in object form ("terser@4": {".": "4.8.1"}).

overrides limitation: one parent level only

Bun supports only one parent level in nested overrides. It ignores deeper nesting like "a>b>c", "a/b/c", and deeper object nesting, and issues a warning.

unsupported pnpm override forms

Bun does not support pnpm's "pkg@" (empty selector) and "-" (remove dependency) forms in overrides. These are skipped with a warning.

lockfile version for nested or version-scoped overrides

When Bun writes a lockfile containing nested or version-scoped rules, it uses lockfileVersion 3, which older versions of Bun cannot read.

Give your agent this brain