Repository navigation
pnpm dedupe --check fails when only registry metadata (deprecated) changed, even though "no dependency resolution would change" #17198
Description
Verify latest release
- I verified that the issue exists in the latest pnpm release
pnpm version
12.15.0
Which area(s) of pnpm are affected? (leave empty if unsure)
Lockfile, CLI (pnpm dedupe --check)
Link to the code that reproduces this issue or a replay of the bug
Self-contained steps below.
Reproduction steps
A lockfile written before a package was npm deprecated. This simulates it by deleting the deprecated: line:
mkdir repro && cd repro
echo '{"name":"repro","private":true,"dependencies":{"@opentelemetry/propagator-jaeger":"1.25.1"}}' > package.json
pnpm install --lockfile-only
sed -i '' '/deprecated: /d' pnpm-lock.yaml # GNU: sed -i '/deprecated: /d'
pnpm install --frozen-lockfile # exit 0
pnpm dedupe --check # exit 1[WARN] deprecated @opentelemetry/propagator-jaeger@1.25.1
[ERR_PNPM_DEDUPE_CHECK_ISSUES] Dedupe --check found changes to the lockfile
The lockfile would be rewritten, but no dependency resolution would change.
Run pnpm dedupe to apply the changes above.
Describe the Bug
deprecated is registry metadata that can change after a version is published. The lockfile stores it, and dedupe --check treats a difference in it as a failure, even though pnpm itself reports that no dependency resolution would change.
In practice this makes dedupe --check non-deterministic as a CI gate:
- The same commit passes locally (warm metadata cache, older metadata) and fails in CI (cold cache, fresh metadata). We hit this today right after regenerating a lockfile:
@opentelemetry/propagator-jaeger@1.25.1and@opentelemetry/sdk-trace-node@1.25.1were deprecated upstream, and CI failed while local runs passed. - Any PR can turn red, even one that doesn't touch dependencies, whenever someone upstream runs
npm deprecateon a transitive dependency.
Related but distinct: #9398 (commands disagreeing on deprecated entries; closed as no longer reproducing on 12.5.1). Here the commands agree. The problem is that a metadata-only drift fails the check.
Expected Behavior
pnpm dedupe --check should only fail when dedupe would change dependency resolution. When the only difference is mutable metadata such as deprecated (the "no dependency resolution would change" case it already detects), it should exit 0, perhaps with a warning that the lockfile metadata is stale.
An alternative would be to keep post-publish-mutable metadata out of the lockfile entirely, but that's a much larger change.
Which Node.js version are you using?
24.22.1
Which operating systems have you used?
- macOS
- Windows
- Linux
If your OS is a Linux based, which one it is? (Include the version if relevant)
Ubuntu (GitHub Actions arm64 runner)
Activity
github-actions commentedon Oct 21, 2026
@dnalborczyk, are you planning to open a pull request for this? If so, reply here and a maintainer will assign the issue to you, so nobody else starts on the same fix.
slophisticated commentedon Oct 21, 2026
Additional version comparison on Windows 10 x64, Node.js 24.20.0, using the same pinned
@opentelemetry/propagator-jaeger@1.25.1dependency in a separate fresh directory for each pnpm version:install --frozen-lockfileafter removingdeprecated:dedupe --checkERR_PNPM_DEDUPE_CHECK_ISSUES, “no dependency resolution would change”Both frozen installs preserved the lockfile without the
deprecated:line. Both check commands left it unchanged. Running plaindedupethen added only that onedeprecated:line in each version; stripping it again produced a byte-for-byte match with the pre-dedupe lockfile. A subsequentdedupe --checkexited 0 in both versions.The test used the public npm registry, an isolated test store, and
--ignore-scriptsfor installs/plain dedupe. This confirms the reported behavior on Windows and shows a difference between these two released versions; I haven't bisected the first affected release or tested a source fix.Written by an agent (OpenAI Codex, GPT-6).
zkochan commentedon Oct 21, 2026
Fix is in #17199.
pnpm dedupe --checknow passes when the lockfile differs only indeprecatednotices. Any other rewrite still fails it, including config-dependency changes. pnpm v11 only compares resolutions in--check, so it was not affected. This covers the whole issue. It does not add the stale-metadata warning you suggested, because the run already prints thedeprecatedwarning during resolution.Written by an agent (Claude Code, claude-opus-5-5).
fix(dedupe): ignore deprecation notices in dedupe --check (#17199)
dnalborczyk commentedon Oct 21, 2026
thank you @zkochan !
Update pnpm to v12.16.1 (#2164)