Yarn Berry Zero-Installs and Git Repository Bloat Management

Short answer: keep Zero-Installs, but regenerate the cache with compressionLevel: 0 and let Yarn's built-in pruning do the rest. Do not move .yarn/cache to Git LFS, and never hand-delete individual archives — the PnP map and lockfile reference each entry by checksum, so removing one file breaks every subsequent install.

Why the cache can't be pruned manually

Zero-Installs works because .pnp.cjs resolves every package to a specific archive in .yarn/cache, identified by checksum. There is no supported "prune the committed cache" command beyond yarn install itself — and that's fine, because Yarn already removes archives that are no longer referenced by the lockfile during each install. The committed cache therefore reflects only your current dependency set. If it feels bloated, the driver is your dependency tree, not leftover files.

The lever that actually helps: compressionLevel

By default Yarn stores cache archives as compressed zips. Compressed binaries don't delta-compress in Git, so every dependency update adds roughly the full archive size to history. Setting the compression level to 0 stores the archives uncompressed:

yarn config set compressionLevel 0
yarn install   # regenerates the whole cache consistently

The working tree gets larger, but the stored files are now plain, diffable content, so Git can delta-compress them across commits. Over the life of a repository this typically produces a smaller history than the default compressed cache. Commit the regenerated cache in a single commit — mixing formats creates noisy diffs.

Why Git LFS is the wrong tool here

LFS pointer-izes the archives, which defeats the core promise of Zero-Installs: a fresh clone that runs without an install step. Every clone and CI job now needs LFS smudging configured, and since zip archives don't delta-compress anyway, LFS buys you little beyond pushing the bytes to a second store. It also adds a failure mode (missing LFS objects) to your most reliability-sensitive path.

If size still matters more than instant startup

The legitimate escape hatch is to abandon Zero-Installs selectively: gitignore .yarn/cache while still committing .pnp.cjs, .yarn/releases, and the lockfile, then run yarn install --immutable in CI (ideally with a warmed global cache). You keep PnP's strictness and deterministic resolution but trade away clone-and-run onboarding. This is a real trade-off, not a free optimization.

Hygiene that keeps the cache small

• Pin the Yarn version via yarnPath (yarn set version) so contributors don't generate divergent cache diffs.
• Run yarn dedupe periodically — dependency count and duplication drive cache size.
• Audit heavy dependencies before adding them; a single large binary package can dwarf the rest of the cache.

Verification

du -sh .yarn/cache
git count-objects -vH
yarn config get compressionLevel

Measure before and after the compression change. Then clone the repo fresh into a temp directory and run your build without yarn install to confirm Zero-Installs still works, and add yarn install --immutable --immutable-cache to CI to guarantee the committed cache matches the lockfile exactly.

One caveat: compressionLevel behavior and defaults vary across Yarn Berry releases — check the version pinned in .yarnrc.yml before assuming a default. And avoid rewriting Git history to purge an old bloated cache unless the bloat is severe; a forward-fixing regeneration is almost always the safer path.