CI Cache Audit: 46% of Dependency Installs in Top JS Repos Run Cacheless

Uncached dependency installs add minutes to every push and PR, and a missing cache-hit guard turns caching into pure overhead. The fix is not better cache-key syntax, which top repos already use; it's turning caching on and adding one if-condition before npm ci.

Sparse-checking the workflow directories of GitHub's 500 most-starred JS/TS repos reveals 2,032 workflows that install dependencies. 1,098 configure a cache; the remaining 934, 46%, never do. At the repo level, 107 of the 380 repos that install dependencies have never enabled caching once. The scan used regex rather than a YAML parser, so caching hidden inside composite actions or reusable workflows is invisible to it; every figure is a lower bound.

Writing cache keys correctly is already the norm. Of 362 hand-written actions/cache steps, 87.6% include a lockfile hash in the key. The gap is simply enabling caching. A separate waste mode is caching node_modules without guarding npm ci: 129 jobs cache node_modules, 65 also run npm ci, and 21 of those (across 7 repos) lack a cache-hit guard. npm ci deletes the restored node_modules and reinstalls from scratch, so the cache download, extract, and save all run for nothing.

The practical checks are a couple of greps plus one manual rule: never cache node_modules without an if: cache-hit condition before npm ci; otherwise cache the package manager's own directory. Small projects may not benefit; if an install takes under two seconds, restoring a cache can be slower than just installing.