v11: verifyDepsBeforeRun and optimistic repeat install ignore version overrides, so a touched package.json looks outdated #17127

Verify latest release

• I verified that the issue exists in the latest pnpm release (latest v11: 11.28.6. Not reproducible on 12.14.0.)

pnpm version

11.28.6 (also 11.6.0)

Which area(s) of pnpm are affected?

CLI, installation (verifyDepsBeforeRun, optimisticRepeatInstall)

Reproduction steps

mkdir repro && cd repro
echo '{ "name": "repro", "private": true, "dependencies": { "is-number": "^7.0.0" } }' > package.json
printf 'overrides:\n  is-number: 7.0.0\n' > pnpm-workspace.yaml

pnpm install                  # lockfile importer gets `specifier: 7.0.0` (the override)
touch package.json            # same content, newer mtime: a formatter, a codegen step, git checkout
pnpm --config.verify-deps-before-run=error exec node -e 0

On 11.28.6:

[ERR_PNPM_VERIFY_DEPS_BEFORE_RUN] The lockfile in /…/repro does not satisfy project of id .

On 12.14.0, the same steps pass. With "is-number": "7.0.0" in package.json (the override's exact value), 11.28.6 passes too.

The same check drives optimisticRepeatInstall. After the touch, pnpm install skips the "Already up to date" fast path and runs the full install. With nodeLinker: hoisted that's a real relink. With "esbuild": "^0.25.0" overridden to 0.25.10, it prints Packages: -25: the skipped other-platform @esbuild/* packages, counted as removed.

Describe the Bug

The lockfile stores the overridden specifier for each importer (specifier: 7.0.0). Once a manifest's mtime is newer than lastValidatedTimestamp, checkDepsStatus calls assertWantedLockfileUpToDate. That compares the raw package.json specifier (^7.0.0) with the lockfile's (7.0.0) without applying overrides, so any project whose specifier differs from an override counts as outdated. pnpm install --frozen-lockfile itself applies the overrides and correctly reports "Lockfile is up to date".

Where this hurts:

• verifyDepsBeforeRun: error fails pnpm run/exec after any package.json write.
• verifyDepsBeforeRun: install (the default) and optimisticRepeatInstall run a full install where nothing changed.
• Tools that rewrite package.json during a build trigger it on every build. expo prebuild rewrites the ios/android scripts, and EAS Build runs pnpm install right after it.

How we found it: on 11.6.0 with nodeLinker: hoisted, that extra full install sometimes never exited after Done in … (the #12297 worker-pool hang, fixed in 11.23.0). It hung our EAS builds in their Prebuild step. We probably hit it earlier on Railway (Linux) too, where verifyDepsBeforeRun started an install before pnpm run that never exited. We worked around it by writing every typescript specifier as exactly the override's version.

Expected Behavior

As on 12.14.0: when the lockfile satisfies the manifest once overrides are applied, a touched package.json is up to date. verify-deps-before-run=error passes, and pnpm install takes the "Already up to date" path.

A possible fix: in assertWantedLockfileUpToDate (deps/status), apply the parsed overrides to each manifest before satisfiesPackageManifest, the way install's read-package hook does. Alternatively, accept a lockfile specifier that equals an override applying to that dependency.

Which Node.js version are you using?

22.23.3

Which operating systems have you used?

• macOS (arm64). The EAS builds where it surfaced ran on macOS too.

_{Drafted with Claude Code. I reproduced it on 11.6.0, 11.28.6 and 12.14.0.}