how to cache test dependencies in CI

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

(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

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

Thread query: how to cache test dependencies in CI

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.