pnpm 12: an optional dependency that fails to fetch is skipped with no warning, and the summary counts it as added #16514

Version

pnpm 12.8.1, Node 24.18.0, macOS 26 (arm64)

Reproduction

mkdir repro && cd repro
printf '{"name":"repro","version":"1.0.0","optionalDependencies":{"is-number":"7.0.0"}}\n' > package.json
pnpm install
# Corrupt the locked integrity so the tarball fetch fails verification
sed -i.bak -E 's/integrity: sha512-[A-Za-z0-9+/=]+/integrity: sha512-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA==/' pnpm-lock.yaml
rm -rf node_modules
pnpm install --frozen-lockfile --store-dir ./fresh-store --config.fetch-retries=0
echo "exit $?"
ls node_modules

The same happens when the registry answers the tarball request with a 404.

Actual

Lockfile is up to date, resolution step is skipped
Packages: +1
+
Progress: resolved 1, reused 0, downloaded 0, added 0, done
Done in 503ms using pnpm v12.8.1
exit 0

node_modules/is-number does not exist. With fetch-retries=0 nothing on stdout or stderr says the package was not installed or why. With retries enabled, the per-attempt [WARN] GET ... error (Failed to verify the integrity ...) lines appear, but the run still ends with the same summary and exit 0.

With --reporter=ndjson, the stream carries a pnpm:fetching-progress event for the package and no matching completion, and no pnpm:skipped-optional-dependency event or any other record of the skip or its reason.

Expected

Skipping an optional dependency that cannot be fetched is fine; #1004 settled that it should succeed "with a warning about optional dependency not found". Here:

• with fetch-retries=0 there is no warning at all, so nothing tells the user the package is missing;
• the summary says Packages: +1 for a package that was not added.

Related: pnpm:skipped-optional-dependency has no reason for a fetch failure (pnpm 11's logger only has unsupported_engine, unsupported_platform, build_failure and resolution_failure), so machine consumers cannot see this case either. A fetch_failure reason carrying the error code (ERR_PNPM_TARBALL_INTEGRITY, an HTTP status) would cover it.

Not the same as #16511 (a platform-skipped optional package's missing subdependency fails the install) or #13317 (platform-skipped optional dependencies dropped when a deleted lockfile is reconstructed).

Why it matters

We run CI that installs a packed CLI and must tell "the registry was unavailable" (retry later, result is did-not-run) from "the package is broken" (fail the build). Under pnpm 10 our test harness observed each fetch outcome through a pnpmfile hooks.fetchers wrapper, which pnpm 12 does not run. Under pnpm 12 the only signal left is a fetch that starts and never finishes in the ndjson stream, so a corrupted or missing optional tarball is indistinguishable from a transient outage, and a run that silently lost an optional dependency reports success.