skip to content

In a monorepo, which binaries does `cypress cache prune` actually delete?

level: seniorimportance: nice to knowfreq 24%

answer

  1. Cleanup that keeps a single version
  2. Which one depends on where you stand
  3. Not the newest, not the most recent
  4. The resolved package version wins
  5. Other packages pay on their next run

basics

~10 s

It deletes every cached Cypress binary except the version resolved from the directory you ran it in. Other packages in the monorepo lose the binaries they pinned, and re-download them on their next run.

solid answer

~40 s

`cypress cache prune` keeps exactly one binary: the version of the `cypress` npm package resolved from the working directory you invoked it in. Everything else in the cache is deleted, regardless of how recently `cypress cache list` says it was used. In a storefront monorepo where `packages/storefront-web` pins Cypress 16.0.0 and `packages/admin-console` is still on an older release, pruning from the storefront package removes the admin console's binary, and its next run downloads hundreds of megabytes again. It is a fine occasional cleanup on a single-version machine, and a poor reflex on a shared build agent. Keying a restored cache on the resolved Cypress version, or converging the monorepo on one version, removes the need for it.

go deeper

for a junior

Recall that Cypress caches one binary per version and that there is a command to clean the cache up. Knowing that something is kept and the rest deleted is enough here.

for a middle

Explain precisely what survives a prune — the version resolved from the current project — and how that differs from what the cache listing reports about recent use.

for a senior

An interviewer expects you to see the blast radius: a shared agent or a shared restored cache where pruning from one package evicts binaries other jobs need, and the cheaper fix of keying the cache on the resolved version.

for a principal

Own the version policy that makes cache maintenance unnecessary: how many Cypress versions the estate tolerates at once, who upgrades them, and whether agents are long-lived enough for cache growth to be a real cost.

## What the cache holds, and why it grows The Cypress binary is stored in a machine-wide cache, one directory per version, so a single download can serve every project on the box. That is a good default and it is also why the folder grows without anyone noticing: each version is hundreds of megabytes, and in a storefront monorepo where `packages/storefront-web`, `packages/checkout` and `packages/admin-console` upgrade on their own schedules, several versions accumulate quickly. On a long-lived build agent with a loosely keyed restore, the cache can end up holding every version the repo has ever used. Four subcommands manage it: | Command | What it does | | --- | --- | | `cypress cache path` | prints the resolved cache directory | | `cypress cache list` | prints each cached version and when it was last used, from the folder's access time; `--size` adds the size, but is slow to compute | | `cypress cache prune` | deletes every cached version **except the currently installed one** | | `cypress cache clear` | deletes everything in the cache | ## The rule prune actually applies This is the part that surprises people. `cypress cache prune` does **not** keep the newest version, and it does **not** keep the recently used ones that `cypress cache list` reports. It keeps exactly one: the version of the `cypress` npm package resolved **from where you invoked the command**. Every other version directory is removed, and the command prints that it deleted all binary caches except that one. So the outcome depends entirely on your working directory: 1. Run it from `packages/storefront-web`, which pins Cypress 16.0.0, and the 16.0.0 binary survives. 2. Every other cached version goes — including the one `packages/admin-console` needs because it has not upgraded yet. 3. The next run in `admin-console` finds no matching binary and downloads its own again, so the "cleanup" traded disk for minutes on the next pipeline run. `cypress cache list` before and after is worth the two seconds. The list is a report; the prune is a policy, and the policy is narrower than the report suggests. ## Where prune belongs, and where it does not - **On a developer machine**, occasionally, after upgrading — this is what it is for. - **On a long-lived, shared build agent**, only if a single Cypress version is in play. Otherwise you are evicting binaries other jobs on that agent will immediately re-download. - **Inside a job whose cache is restored from a shared key**, never as a reflex. Pruning at the end of a job and then saving the cache silently deletes what sibling jobs on other versions rely on. - **In a prebuilt run image**, it is pointless — the image is rebuilt rather than pruned, and an image built from `cypress/included` already carries exactly one Cypress. ## Better levers than pruning - **Key the cache on the resolved Cypress version.** A restore key that includes the version stops the snowball at the source, so nothing needs evicting. - **Converge the monorepo on one version.** Most cache bloat is a symptom: several packages pinning different Cypress versions. One version means one binary, and `prune` becomes a no-op. - **Use `cypress cache list --size` before you decide.** Confirm the cache is genuinely the thing filling the disk, and accept that computing sizes is slow enough that it belongs in a diagnostic step, not in every job. - **Reach for `cypress cache clear` only deliberately.** It removes every cached binary, and after it you must run `cypress install` again before Cypress will launch at all. ## The cheap sanity check Before automating any cache maintenance, run the three commands in the environment that will execute them: ```bash npx cypress cache path npx cypress cache list npx cypress cache prune ``` If `cypress cache path` prints a directory you did not expect — because `CYPRESS_CACHE_FOLDER` is set in one step and not another — then prune is about to operate on a cache you were not thinking about. And if `cypress cache list` shows versions belonging to other packages in the monorepo, prune is about to delete them regardless of how recently they were used.

  • How does cypress cache prune differ from cypress cache clear?
    `prune` deletes every cached version except the one resolved from the current project, so Cypress can still launch there afterwards. `clear` empties the cache completely, and you must run `cypress install` again before Cypress will start at all. Use `clear` when you suspect a corrupt or half-extracted binary, and `prune` when you only want to reclaim disk from versions you no longer use.
  • What does cypress cache list tell you, and what does the --size flag cost?
    It prints a table of the cached versions with when each was last used, derived from the folder's access time. Adding `--size` also reports the disk each version occupies, but calculating that walks every file and is noticeably slow, so it belongs in a deliberate diagnostic step rather than in every pipeline job.

saying these in an interview costs you the question

  • Thinks prune keeps the most recently used versions
  • Thinks prune keeps the newest cached version
  • Runs prune on a shared agent serving several versions
  • Confuses prune with clear and expects a launch to work
  • Assumes the working directory does not affect the result