pnpm v11 minimumReleaseAge Causes Dependabot CI Failures ─ Summary of Root Cause, Workarounds, and Upstream Status

Introduction

After upgrading a project to pnpm v11, CI for PRs created by Dependabot suddenly started failing.

[ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION] 1 lockfile entries failed verification:
  caniuse-lite@1.0.30001802 was published at 2026-07-06T04:58:52.000Z,
  within the minimumReleaseAge cutoff (2026-07-05T09:23:26.106Z)

Not a directly depended-upon package, but the transitive dependency caniuse-lite is being rejected for installation because it was judged as "too recently published."

This is caused by the supply chain protection feature minimumReleaseAge introduced in pnpm v11. In this article, I investigated why this happens, what workarounds are available, and the current state of upstream discussions.

Prerequisites / Environment

• pnpm: v11 (minimumReleaseAge enabled by default)
• CI: GitHub Actions (pnpm install --frozen-lockfile)
• Dependency management: Dependabot (version updates)
• Problematic package: caniuse-lite (transitive dependency via browserslist, new versions published almost every day)

What is minimumReleaseAge

This is a supply chain attack mitigation feature introduced in pnpm v11. It rejects installation of packages that have not been published for a certain amount of time.

• Default value: 1440 minutes (24 hours)
• Purpose: Since malicious packages are often detected and removed within a few hours of publication, setting a "cooling period" helps prevent damage
• Configuration location: pnpm-workspace.yaml (in pnpm v11, pnpm-specific settings in .npmrc are not read)

# Default is 1440 (minutes). Set to 0 to disable
minimumReleaseAge: 1440

Why This Becomes a Problem with Dependabot

How It Occurs

1. Dependabot detects a new version of a directly depended-upon package and creates a PR
2. At PR creation, pnpm install regenerates the lockfile → transitive dependencies are resolved to their latest versions
3. At that moment, the latest version of caniuse-lite happens to have been published just a few hours ago
4. The generated lockfile records the "just published" version
5. CI runs pnpm install --frozen-lockfile → lockfile verification → ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION

The Fundamental Design Issue

This is the core of the problem. pnpm's minimumReleaseAge is designed as verify-after-resolve.

In other words, the problem is that the resolver does not fall back to an older version that satisfies the conditions instead of a version judged as "too new."

Another Trap with --frozen-lockfile

--frozen-lockfile only verifies the contents of the lockfile and does not re-resolve. If the lockfile generated in Dependabot's runner environment contains a version that is too new, there is nothing the CI side can do. It is a verification-only code path with no room for fallback in the first place.

Comparison of Workarounds

1. minimumReleaseAgeExclude (Most Practical)

Exclude specific packages from the policy in pnpm-workspace.yaml.

minimumReleaseAgeExclude:
  - caniuse-lite

caniuse-lite is updated almost every day and is the Can I Use database, so the risk of supply chain attacks is low. Excluding it in a targeted manner is a realistic compromise.

However, this is not a fundamental solution. Today it happened with caniuse-lite, but tomorrow the same thing could happen with a different frequently-updated package.

2. Dependabot cooldown Setting

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 3
      semver-patch-days: 2

Dependabot waits a certain period after detecting a new version before creating a PR. However, this only delays the timing of PR creation for direct dependencies. It does not solve the problem of transitive dependencies being resolved to the latest version during pnpm install at PR creation time.

Also, if you are using wildcard groups (patterns: ["*"]) in Dependabot, if even one package in the group has passed the cooldown, other packages that are still within the period will also be included in the PR together. For details, see "The trap of Dependabot's wildcard group disabling cooldown and how to deal with it."

3. pnpm-exclude-newer

pnpm-exclude-newer is a tool that launches a local registry mirror and generates a lockfile with versions published after a cutoff date hidden. It provides pnpm with functionality equivalent to uv's --exclude-newer.

pnpm dlx pnpm-exclude-newer

It is the only tool where the age restriction applies to all dependencies including transitive ones, but since Dependabot cannot run custom install commands, integrating it into Dependabot's workflow is practically impossible.

4. Wait and Re-run

The default for minimumReleaseAge is 24 hours, but if a package is published immediately after Dependabot generates the lockfile, taking into account the time lag until CI runs (waiting for PR creation, queue wait, etc.), there are cases where you may need to wait up to about 48 hours from publication. It will naturally pass once enough time has elapsed.

Upstream Status

Related Issues

What Has Been Fixed vs. What Hasn't

#10100 (across major versions) was fixed in v10.20.0. For example, if lodash@5.0.0 is too new, it falls back to lodash@4.17.21.

However, #11203 (within the same range) is not yet fixed. If lodash@4.18.1 is too new, it should fall back to lodash@4.18.0 within the same range, but currently it falls back to the older lodash@4.17.23. It should be addressable as a natural extension of the #10100 fix, but no one has submitted a PR yet.

Is It Worth Submitting a PR

The resolver fix (same-range fallback) can reference the existing fix from #10100, and the scope of changes is limited. However, the --frozen-lockfile verification path is a separate code path, so its handling needs separate consideration.

It would be best to comment on the Issue and confirm the maintainers' direction before starting work on a PR.

Summary

• pnpm v11's minimumReleaseAge is an important supply chain protection feature, but it has a design gap where fallback for transitive dependencies is not implemented
• In combination with Dependabot, CI randomly fails due to transitive dependencies that users cannot control (such as caniuse-lite)
• The most practical short-term workaround is to exclude frequently-updated packages using minimumReleaseAgeExclude
• A fundamental fix requires implementing resolver fallback on the pnpm side (#11203)
• If you have encountered the same issue, you can contribute to raising upstream priority by adding 👍 or comments to the Issue

Reference Links

• pnpm Settings — minimumReleaseAge
• pnpm 11.0 Release Notes
• pnpm-exclude-newer
• Dependabot cooldown settings
• Configuring minimum release age across npm, pnpm, and yarn