GitHub Actions setup-node cache "Some specified paths were not resolved"
actions/setup-node looks for a package manager lockfile to key and locate the dependency cache; when it cannot find one at the expected path, it warns that paths were not resolved and skips caching.
What this error means
setup-node logs "Some specified paths were not resolved, unable to cache dependencies." Dependency installs then run uncached on every run.
Warning: Some specified paths were not resolved, unable to cache dependencies.Diagnose it: was the cache hit, and was it the right one?
Cache bugs split into three shapes and they need different fixes: the cache never saved, it saved but the key never matches on restore, or it restored a stale entry through a restore-keys prefix and is now poisoning the build. The step output tells you which one you have.
- uses: actions/cache@v4
id: cache
with:
path: ~/.npm
key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-npm-
- name: What happened
run: |
echo "exact hit: ${{ steps.cache.outputs.cache-hit }}"
echo "key used: ${{ steps.cache.outputs.cache-matched-key }}"Common causes
Lockfile missing or in a subdirectory
setup-node expects package-lock.json/yarn.lock at the default location, but it is absent or nested where the action does not look.
cache-dependency-path not set for monorepos
In a monorepo the lockfile lives elsewhere and cache-dependency-path was not provided.
How to fix it
Point setup-node at the lockfile
- Commit the lockfile so it exists in CI.
- Set cache and cache-dependency-path to the lockfile location.
- For monorepos, glob all relevant lockfiles.
- uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
cache-dependency-path: packages/*/package-lock.jsonCache limits that produce confusing failures
- Repository cache is capped at 10 GB. Past that, GitHub evicts least-recently-used entries, so a large cache can silently stop persisting.
- Caches are scoped by branch. A cache written on a feature branch is not visible to another feature branch, only to its base and its own descendants.
- An entry not read for 7 days is evicted, so a rarely-run workflow effectively never has a warm cache.
- Restoring a cache built for a different tool version is worse than a cold start, because you get a corrupted tree instead of a clean install. Always include the tool version in the key.
How to prevent it
- Keep the lockfile committed and discoverable.
- Set cache-dependency-path in monorepos.
- Confirm setup-node reports a resolved cache path.