Repository navigation
Cache the metadata directory reported by pnpm cache path #37
Description
Problem
pnpm 11.22.0 added pnpm cache path, which reports the metadata cache directory. The release notes explicitly recommend caching this directory in CI because it includes the lockfile verification log and lets an unchanged lockfile skip repeated supply-chain policy checks.
pnpm/setup currently restores and saves only the directory returned by pnpm store path when cache: true:
https://github.com/pnpm/setup/blob/main/src/cache-restore/run.ts#L40-L44
As a result, the content-addressable package store is cached, but the separate metadata cache is not. Projects using settings such as minimumReleaseAge or trustPolicy must repeat registry-backed lockfile verification on later CI runs even when the lockfile is unchanged.
Proposed behavior
When cache: true:
- Restore and save both
pnpm store pathandpnpm cache path. - Preserve compatibility with pnpm 11.0–11.21 by gracefully falling back to store-only caching when
pnpm cache pathis unavailable. - Keep the existing cache key behavior unless separate store and metadata keys are preferable.
An opt-in input for metadata caching would also work, although including it by default appears consistent with pnpm 11.22's CI guidance.
References
- pnpm 11.22.0 release notes: https://github.com/pnpm/pnpm/releases/tag/v11.22.0
- Current cache implementation: https://github.com/pnpm/setup/blob/main/src/cache-restore/run.ts#L40-L44
Environment
- pnpm/setup v2.0.2 and current
main - pnpm 11.22.0
Activity
Blacksmoke16 commentedon Aug 24, 2026
I think #30 would cover this yea?
zkochan commentedon Aug 28, 2026
@Blacksmoke16 — partly. #30 has landed on
main, so the motivating problem here is solved, but the proposed behaviour is not implemented, so I am leaving this open.What shipped. The lockfile verification log (
lockfile-verified.jsonl) is restored from the directorypnpm cache pathreports, before the install, and saved afterwards under its own key —pnpm-lockfile-verified-<OS>-<arch>-<lockfile hash>, with no prefix fallback, since a verdict is only valid for the exact lockfile it was recorded for. It is cached regardless of thecacheinput, because the file is under a kilobyte and the check it saves costs seconds. Releases withoutpnpm cache pathfall back topnpm config get cacheDirand then to pnpm's per-platform default, so pnpm 11.0–11.21 keep working as you asked.So projects using
minimumReleaseAgeortrustPolicyno longer repeat registry-backed verification when the lockfile is unchanged.What did not. Only that one file is cached, not the directory. The rest of what
pnpm cache pathreports — the registry metadata cache — is still refetched every run, and caching it would speed up resolution independently of the verification log. That is the "restore and save bothpnpm store pathandpnpm cache path" half of your proposal, and it is still worth doing, so this stays open for it.Two things worth settling if someone picks it up: whether the metadata cache should be keyed on the lockfile at all (it is not lockfile-derived, so a prefix-matched or date-based key may serve it better), and whether it should follow
cache: trueor be unconditional like the verification log.