Yarn Berry Cache Configuration for Zero-Installs and Registry Consistency

Zero-Installs Cache Management

Yarn Berry (v2+) introduces a project-local cache stored as zip archives in .yarn/cache. This architecture supports Zero-Installs, allowing the cache to be committed to version control so that every environment uses identical artifacts without requiring a network fetch during yarn install.

When utilizing Zero-Installs, the project relies on the committed cache as the source of truth. However, a conflict arises when a private registry allows package mutation without a version increment, or when the yarn.lock integrity hashes must be updated to reflect registry changes while maintaining a consistent state across a distributed team.

There is a design trade-off between committing the full cache for absolute reproducibility and relying on registry fetches to avoid bloated repository sizes. It remains unclear how to best balance this when the registry content may shift independently of the version number.

• What is the recommended strategy for invalidating specific committed cache entries in a Zero-Installs workflow without forcing a full cache purge for all contributors?
• How does Yarn Berry handle the reconciliation between a committed cache archive and a modified integrity hash in the lockfile during a CI build?