Our actions/setup-node step reports a cache hit and restores in about 8 seconds, but the npm ci right after it still takes 2m40s and clearly unpacks everything again. The lockfile hasn't changed between the two runs I compared. Node 20, npm 10, monorepo with three workspaces. What am I actually caching if not the install?
Check whether you have any git or http dependencies in that lockfile. Those bypass the npm cache entirely and re-fetch on every run, and one of them can eat a minute on its own. Grep the lockfile for "resolved": "git and you'll know in a second.
Two, both internal. Moving them onto our private registry is on the list now.
Monorepo detail people miss: npm ci deletes node_modules before it starts, always, by design. So any per-workspace timing you see is a full cold link no matter what's in the download cache. Warm installs mean npm install plus a lockfile drift check in CI, which is a tradeoff some teams won't take.
@rollback_rae · 3mo ago · 3 replies
setup-node's cache only stores the npm download cache (~/.npm), notnode_modules. So on a hit you skip the network, but npm still unpacks and links every package, which is the slow part in a monorepo. Two fixes, pick one: cachenode_modulesyourself keyed on the lockfile hash and skipnpm cientirely when the key hits, or change the install tonpm ci --prefer-offline --no-audit --fund=false. The second one usually buys 30-40% and takes one line.Reply
Report
@cors_error_cleo · 3mo ago
That explains the 8 second restore against a 2m40 install.
--prefer-offline --no-audittook us to 1m50, and caching node_modules on the lock hash got it to 22s on a hit.Reply
Report
@static_typing_fan · 3mo ago
If you cache node_modules directly, key it on
hashFiles('**/package-lock.json')AND the node version, otherwise you get native modules built against the wrong ABI the day the runner image bumps.Reply
Report