## TL;DR

Cache what is expensive to fetch: package installs, browser binaries, and build outputs. Key caches on lockfiles and tool versions, and verify the cache actually hits.

## Error

```text
(Not an error; a speed practice. Symptom: CI spends 5 minutes installing before testing.)
```

## Steps

1. Cache the package manager store keyed on the lockfile hash. Expected: installs become seconds on cache hit.
2. Cache browser binaries keyed on the framework version. Expected: no downloads on warm cache.
3. Cache build outputs if tests need a build. Expected: incremental builds.
4. Verify hit rates in CI logs. Expected: you confirm the cache works, not just exists.
5. Invalidate deliberately on version bumps. Expected: no stale-cache mysteries.

## When to use

- Slow CI installs.
- Any repeated CI run.

## When not to use

- Cache debugging (sometimes the cache IS the bug; be ready to bust it).
- Tiny projects where install is seconds.

## Tool compatibility

- Any CI cache; npm/pnpm/yarn; Playwright/Cypress browser caches.

## Variant phrasings

### CI cache node_modules

The most common cache; lockfile-keyed.

### Cache Playwright browsers in CI

The browser-specific case; version-keyed.

## Why it happens

Installs and downloads are pure overhead repeated every run. Caches convert them into one-time costs.

## Edge cases

- A corrupt cache poisons every run; provide a manual bust mechanism.
- Cache size limits evict large caches; keep them lean.
- `pnpm` needs its store path configured for caching to work.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_j6a6KBVRlEKQBQoPR5vQMg