pnpm install fails on any pnpm newer than 9. CI does not see it because CI pins pnpm 9.
What happens
$ pnpm install --ignore-scripts=false # pnpm 11.25.0
@buf/meshtastic_api.bufbuild_es@1.6.0-20240110092216-3a147af14302.1 has no "integrity" field, so its downloaded tarball cannot be verified
@buf/meshtastic_api.bufbuild_es@1.7.2-20240110092216-3a147af14302.1 has no "integrity" field, so its downloaded tarball cannot be verified
@buf/meshtastic_api.connectrpc_es@1.3.0-20240110092216-3a147af14302.1 has no "integrity" field, so its downloaded tarball cannot be verified
@buf/meshtastic_protobufs.bufbuild_es@1.7.2-20240216123215-6b07c41c68c9.1 has no "integrity" field, so its downloaded tarball cannot be verified
The lockfile contains entries that the active policies reject.
| pnpm |
result |
| 9.15.9 |
ok |
| 10.34.4 |
ERR_PNPM_MISSING_TARBALL_INTEGRITY |
| 11.25.0 |
rejected by the lockfile policy, as above |
Why
The @buf packages come from buf.build's npm registry (.npmrc: @buf:registry=https://buf.build/gen/npm/v1). That registry generates tarballs on demand and its packument carries only a tarball URL:
$ curl -s 'https://buf.build/gen/npm/v1/@buf%2Fmeshtastic_api.bufbuild_es' | jq '.versions["1.7.2-20240110092216-3a147af14302.1"].dist | keys'
[ "tarball" ]
No integrity, no shasum. pnpm 8 — which wrote these entries — recorded nothing. pnpm 10 made a missing hash a hard error.
Newer pnpm does compute the hash from the downloaded tarball, but only on a fresh resolution; it will not reuse an entry it has already rejected. So pnpm install --no-frozen-lockfile does not repair it, and deleting the lockfile does but moves every unrelated dependency at the same time.
Worth knowing: #101 is green for a misleading reason
Dependabot #101 ("Bump pnpm from 8.15.3 to 10.34.4") passes CI, but it bumps the pnpm devDependency in package.json. The pnpm that actually resolves the install is set by pnpm/action-setup in .github/workflows/ci.yml, which is pinned to version: 9. So #101 does not exercise pnpm 10 at all. Moving action-setup to 10 or 11 — on its own, or via a future dependabot bump — would break build and quality immediately.
Fix
Write the four hashes into the existing entries and change nothing else. Each is the sha512 of the tarball buf.build serves today, byte-identical to what pnpm 11 computes when it resolves these packages from scratch. PR to follow.
pnpm installfails on any pnpm newer than 9. CI does not see it because CI pins pnpm 9.What happens
ERR_PNPM_MISSING_TARBALL_INTEGRITYWhy
The
@bufpackages come from buf.build's npm registry (.npmrc:@buf:registry=https://buf.build/gen/npm/v1). That registry generates tarballs on demand and its packument carries only a tarball URL:No
integrity, noshasum. pnpm 8 — which wrote these entries — recorded nothing. pnpm 10 made a missing hash a hard error.Newer pnpm does compute the hash from the downloaded tarball, but only on a fresh resolution; it will not reuse an entry it has already rejected. So
pnpm install --no-frozen-lockfiledoes not repair it, and deleting the lockfile does but moves every unrelated dependency at the same time.Worth knowing: #101 is green for a misleading reason
Dependabot #101 ("Bump pnpm from 8.15.3 to 10.34.4") passes CI, but it bumps the
pnpmdevDependency inpackage.json. The pnpm that actually resolves the install is set bypnpm/action-setupin.github/workflows/ci.yml, which is pinned toversion: 9. So #101 does not exercise pnpm 10 at all. Movingaction-setupto 10 or 11 — on its own, or via a future dependabot bump — would breakbuildandqualityimmediately.Fix
Write the four hashes into the existing entries and change nothing else. Each is the sha512 of the tarball buf.build serves today, byte-identical to what pnpm 11 computes when it resolves these packages from scratch. PR to follow.