Cache the metadata directory reported by pnpm cache path

[miky-mfw]

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 path and pnpm cache path.
• Preserve compatibility with pnpm 11.0–11.21 by gracefully falling back to store-only caching when pnpm cache path is 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

[Blacksmoke16]

I think #30 would cover this yea?

[zkochan]

@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 directory pnpm cache path reports, 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 the cache input, because the file is under a kilobyte and the check it saves costs seconds. Releases without pnpm cache path fall back to pnpm config get cacheDir and then to pnpm's per-platform default, so pnpm 11.0–11.21 keep working as you asked.

So projects using minimumReleaseAge or trustPolicy no 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 path reports — 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 both pnpm store path and pnpm 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: true or be unconditional like the verification log.