pnpm 12.15 can pin lockfile hashes to the uncompressed tar
A new lockfile.integrityTarget setting stops your lockfile changing every time a registry recompresses a package, by hashing the tar contents instead of the compressed file.
pnpm 12.15.0 shipped on 21 October with a new lockfile.integrityTarget: tar setting. pnpm’s lockfile normally stores a hash of the compressed tarball a registry serves for each package version. If that registry ever recompresses its tarballs, the hash changes and so does your lockfile, even though nothing about the package actually changed. The new setting hashes the uncompressed tar contents instead, which stays stable across recompression, by learning a version’s tar hash from the store or downloading it once.
The same release adds support for registries that serve uncompressed tars over zstd or gzip, declared with serverType: pnpr, alongside a maxTarballUnpackedSize setting that caps unpacked package size at 4 GiB by default. pnpm-workspace.yaml can now delegate settings to other YAML files through a new include field. On the performance side, pnpm reports installing 1,352 packages from a warm store on a 12-core Mac now takes 1.3 seconds, down from 2.2, and lockfile verification on a large workspace now peaks at 1.8 to 2.0 GB of memory instead of 2.6 to 3.7 GB.
# pnpm-workspace.yaml
lockfile:
integrityTarget: tarWhy it matters: anyone who has had a pnpm-lock.yaml churn with no real dependency change knows the recompression problem, it shows up as noisy diffs and false cache invalidation in CI. Turning on integrityTarget: tar removes that specific source of lockfile noise without changing what gets installed.