pnpm via renovate errors with ERR_PNPM_TRUST_DOWNGRADE for semver@6.3.1

[thasmo]

commands:

pnpm update --no-save lenis@1.3.20 --lockfile-only --ignore-scripts --ignore-pnpmfile
pnpm dedupe --ignore-scripts

Progress: resolved 1, reused 0, downloaded 0, added 0
Progress: resolved 23, reused 0, downloaded 0, added 0
Progress: resolved 26, reused 0, downloaded 0, added 0
Progress: resolved 210, reused 0, downloaded 0, added 0
Progress: resolved 334, reused 0, downloaded 0, added 0
 ERR_PNPM_TRUST_DOWNGRADE  High-risk trust downgrade for "semver@6.3.1" (possible package takeover)

This error happened while installing the dependencies of @somehow-digital/eslint-config@5.0.2
 at eslint-plugin-react-hooks@7.0.1
 at @babel/core@7.29.0

Trust checks are based solely on publish date, not semver. A package cannot be installed if any earlier-published version had stronger trust evidence. Earlier versions had provenance attestation, but this version has no trust evidence. A trust downgrade may indicate a supply chain incident.

AFAIK there was no other version prior to 6.3.1 which had attestation.

Do I miss something here or why would 6.3.1 fail to install?

Update: Actually it's the dedupe command which fails after the update command.

[thasmo]

There are only two different semver versions referenced in the lock file:

• semver@7.7.4
• semver@6.3.1

Wondering why a dedupe would fail. Is it trying to downgrade the 7.7.4 to 6.3.1? 🤔

[sueun-dev]

Your instinct is right — this is a false positive, and it's a known issue tracked in pnpm/pnpm#10202.

Why semver@6.3.1 triggers it

The trust check is date-based, not semver-based. pnpm looks at all published versions of the package (across all majors) and asks: "did any version published before this one have stronger trust evidence?" It doesn't restrict that comparison to the same major version.

semver@7.x has provenance attestation. Because the v6 and v7 branches were both being maintained and published around the same time, some semver@7 releases with provenance have an earlier publish timestamp than semver@6.3.1 (which has no provenance). So pnpm sees a trust downgrade, even though they're completely different major version branches.

Why dedupe fails but install doesn't

pnpm dedupe re-resolves the full dependency graph including all transitive deps, and it re-runs trust validation on everything in that pass. pnpm install may have already recorded semver@6.3.1 in the lockfile and skipped re-checking it. Dedupe always re-evaluates.

How to fix it

If you're on pnpm v10.22+, trustPolicyExclude lets you carve out specific packages:

# pnpm-workspace.yaml
trustPolicy: no-downgrade
trustPolicyExclude:
  - 'semver@6'

If you're on v10.27+, trustPolicyIgnoreAfter is a time-based alternative that bypasses the check for packages published more than N minutes ago — useful if you have multiple old transitive deps hitting the same issue:

# pnpm-workspace.yaml
trustPolicy: no-downgrade
trustPolicyIgnoreAfter: 525600  # 1 year in minutes

If you'd rather not set trustPolicy at all, removing it (or setting trustPolicy: off) disables the check entirely — since it's opt-in, you'd just be going back to the default behavior.

The underlying cross-major comparison behavior was flagged in the issue above and closed without changing the logic (the fix was only to improve the error message). So trustPolicyExclude is the practical path forward until that gets revisited.