Some registries generate tarballs on demand and cannot list an integrity in
their packument. pnpm then wrote integrity-less lockfile entries on the first
install and failed the next one with ERR_PNPM_MISSING_TARBALL_INTEGRITY, unable
to install from its own lockfile.
Compute the missing integrity from the downloaded bytes and write it into the
resolution before the lockfile is built:
- Add an optional `resolutionNeedsFetch` contract to the fetcher API (backward
compatible, since custom fetchers come from hooks). The remote-tarball fetcher
reports it when a resolution lacks integrity; the picked fetcher's signal flows
through PackageResponse -> ResolvedPackage so nothing re-derives it.
- The package requester downloads such tarballs (including under --lockfile-only /
skipFetch / not-installable) and fills the computed integrity onto the resolution
via the already-running `fetching` promise, so dependency resolution isn't
blocked. The deps-resolver awaits only the flagged entries before updateLockfile,
because the integrity feeds the global virtual-store paths.
- Move read-side enforcement into the npm resolver's lockfile verifier
(MISSING_TARBALL_INTEGRITY): reject a registry/http(s) tarball entry whose
integrity is missing/empty/non-string, fail-closed, before the URL-keyed and
semver short-circuits. Drop the earlier read-side auto-heal (a missing-field
bypass). Harden against tampered lockfiles (non-string tarball/integrity).
- Reuse the fetcher picked during resolution on the fetch path instead of running
pickFetcher (and a custom fetcher's async canFetch) twice per package.
Mirrored in pacquet: PrefetchingResolver computes the integrity for integrity-less
tarball resolutions during resolution (FetchTarballForResolution::run), deduped per
URL with a singleflight cache.
Closespnpm/pnpm#12145.
---------
Co-authored-by: Zoltan Kochan <z@kochan.io>
