deploy --legacy silently replaces locked versions that fail minimumReleaseAge (11.28.6 fails with ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION) #17209

Last pnpm version that worked

11.28.6

pnpm version

12.15.0 (also 12.14.0)

Code to reproduce the issue

mkdir deploy-legacy-repro && cd deploy-legacy-repro
mkdir -p packages/app packages/lib
echo '{"name":"repro","private":true,"packageManager":"pnpm@12.15.0"}' > package.json
printf 'packages:\n  - packages/*\n' > pnpm-workspace.yaml
echo '{"name":"lib","version":"1.0.0","dependencies":{"supports-color":"^7.1.0"}}' > packages/lib/package.json
echo '{"name":"app","version":"1.0.0","dependencies":{"lib":"workspace:*"}}' > packages/app/package.json

# Locks supports-color@7.2.0 (published 2020-08-28)
pnpm install

# A cutoff of 2020-03-01: after 7.1.0 (2019-09-27), before 7.2.0
export PNPM_CONFIG_MINIMUM_RELEASE_AGE=$(node -e 'console.log(Math.floor((Date.now() - Date.parse("2020-03-01")) / 60000))')

pnpm install --frozen-lockfile                   # ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION
pnpm deploy --filter app --prod out-modern       # ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION
pnpm deploy --filter app --prod --legacy out     # exits 0
ls out/node_modules/.pnpm | grep supports-color  # supports-color@7.1.0

Expected behavior

pnpm deploy --legacy uses the versions recorded in the shared pnpm-lock.yaml. When a locked version fails minimumReleaseAge, it fails with ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION, the way pnpm install --frozen-lockfile and the non-legacy pnpm deploy do on 12.15.0, and the way pnpm deploy --legacy does on 11.28.6.

Actual behavior

pnpm deploy --legacy exits 0 and the deployed node_modules contains supports-color@7.1.0, a version that is not in pnpm-lock.yaml. The only output is the usual "Shared workspace lockfile detected but configuration forces legacy deploy implementation." warning, so nothing signals that the deployed tree differs from the lockfile.

Same script, per version:

(10.33.2 also ships 7.1.0 here, but 10.x does not verify the lockfile against minimumReleaseAge at all, so its install --frozen-lockfile succeeds with 7.2.0 too.)

Additional information

It looks like deploy --legacy on 12 re-resolves the deployed project's dependencies against the registry instead of taking them from the shared lockfile, with minimumReleaseAge applied as a resolution filter rather than as a lockfile check.

Possibly the same root cause, seen in a larger workspace (about 80 projects, about 2,100 lockfile entries, shamefullyHoist: true, publicHoistPattern: ['*']) with no release-age policy involved: on 12.14.0, deploy --legacy linked @aws-sdk/client-s3@3.1079.0 (and five other @aws-sdk/* clients at the same version) to @smithy/node-http-handler@4.9.3, while their lockfile snapshots pin 4.12.0. Only another, non-deployed project's dependency (@aws-sdk/client-lambda@3.1079.0) pinned 4.9.3. The same deploy bound get-intrinsic and get-proto to es-object-atoms@1.1.2 (lockfile: 1.1.1) and gave debug@4.4.3 supports-color@7.2.0 (lockfile: 8.1.1). pnpm 10.33.2's deploy --legacy of the same lockfile matched the lockfile for every one of about 1,400 dependency links. I couldn't reduce that case to a small workspace: a fresh install dedupes to one copy, and a small workspace whose lockfile holds both copies (installed in two steps, with and without a workspace-package hop and the hoisting settings above) deploys correctly. The deploy output also held a second, hash-addressed copy of some packages, which may be #17116.

Non-legacy deploy is not an option for that workspace: it fails with ERR_PNPM_DEPLOY_AMBIGUOUS_PEER (a workspace package's pino peer resolves to two versions).

Node.js version

v24.18.0

Operating System

macOS 27.0.1 (arm64)