Using Yarn Berry Zero-Installs to Speed Up CI by Committing the Dependency Cache

Problem: CI builds break when the registry is unavailable

Every time CI runs yarn install it reaches out to the npm registry to fetch tarballs. If the registry is slow, throttled, or temporarily down, the job fails and you lose reproducibility.

Thesis: Commit the cache, skip the fetch

Yarn Berry’s Zero-Installs feature stores the exact tarballs in .yarn/cache and pins the Yarn release in .yarn/releases. When those directories are committed, a fresh checkout can run yarn install --immutable without touching the network.

How to enable Zero-Installs

1. Upgrade to Yarn Berry (v2+). Run yarn set version berry to get a release in .yarn/releases.
2. Add or edit .yarnrc.yml at the repo root:

# .yarnrc.yml
nodeLinker: node-modules
yarnPath: .yarn/releases/yark-*.cjs
enableImmutableInstalls: true
enableGlobalCache: false

Note: the exact key names may differ between Berry releases; verify with yarn --version and the release notes.

Verification steps

1. Run yarn --version to confirm a Berry release (e.g., 3.x).
2. Check that .yarnrc.yml contains yarnPath pointing into .yarn/releases and enableImmutableInstalls: true.
3. In a disposable branch, execute yarn install --immutable. The command should finish quickly and git status should show only files under .yarn as newly tracked.

Trade‑off and limitation

The benefit is deterministic builds and immunity to registry outages. The cost is a larger Git repository: the cached tarballs increase clone time and storage. Content‑addressable storage deduplicates identical versions, but the initial commit can still be sizable.

Zero-Installs does not eliminate native build steps. Packages that compile from source still need compilers and system libraries in CI; the cache only provides the tarball.

Actionable next step

Pick a low‑risk project that already uses Yarn Berry. Enable Zero-Installs, commit .yarn/releases and .yarn/cache, then run CI with yarn install --immutable. Verify that the build passes without network errors and that the repository size growth is acceptable. If the repo becomes too large, consider partial caching or an artifact store instead of committing the full cache.