how to cache test dependencies in CI
Caches test dependencies in CI: node_modules, browsers, and build outputs. Use when CI installs dominate runtime. Not for test logic.
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
- Cache the package manager store keyed on the lockfile hash. Expected: installs become seconds on cache hit.
- Cache browser binaries keyed on the framework version. Expected: no downloads on warm cache.
- Cache build outputs if tests need a build. Expected: incremental builds.
- Verify hit rates in CI logs. Expected: you confirm the cache works, not just exists.
- 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.
pnpmneeds its store path configured for caching to work.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_j6a6KBVRlEKQBQoPR5vQMg
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.