Verify latest release
pnpm version
No response
Which area(s) of pnpm are affected? (leave empty if unsure)
No response
Describe the Bug
The minimumReleaseAge configuration option is not enforced when running pnpm install (or its variants with --fix-lockfile, --frozen-lockfile, --lockfile-only) if the lockfile already contains a dependency version that violates the constraint. This means that once a violating version is present in pnpm-lock.yaml, pnpm allows installation to proceed without validation, effectively bypassing the minimumReleaseAge protection.
This behavior is inconsistent with other security-related flags like strictDepBuilds, which validates configuration constraints regardless of whether dependencies existed in the lockfile before the flag was enabled.
Reproduction steps
I conducted tests to see in what scenarios pnpm didn't behave as expected, and their reproduction steps are outlined in their respective test scenario.
Test Environment
OS: Windows 11 (version 25H2 build 26200.7462)
pnpm version: 10.27.0
Test package: zod
- Version
4.3.4: Older than minimumReleaseAge ✅
- Version
4.3.5: Newer than minimumReleaseAge ❌
Configuration:
minimumReleaseAge: 10080 # 7 days in minutes
Table summarizing test cases and results
| Test Case |
Scenario |
Command |
Lockfile Exists (zod version installed) |
Respects minimumReleaseAge |
| 1a |
Fresh install of violating version |
pnpm add zod@4.3.5 |
No |
✅ (blocked) |
| 1b |
Fresh install of violating version |
pnpm add zod@4.3.5 |
Yes (none) |
✅ (blocked) |
| 2 |
Reinstalling exiting violating version |
pnpm add zod@4.3.5 |
Yes (4.3.5) |
❌ |
| 3 |
Upgrade to latest (violating) |
pnpm add zod@latest |
Yes (4.3.4) |
✅ (blocked) |
| 4 |
Upgrade to specific violating version |
pnpm add zod@4.3.5 |
Yes (4.3.4) |
✅ (blocked) |
| 5a |
Manual package.json edit |
pnpm install |
Yes (4.3.4) |
✅ (blocked) |
| 5b |
Manual package.json edit |
pnpm install --fix-lockfile |
Yes (4.3.4) |
✅ (blocked) |
| 5c |
Manual package.json edit |
pnpm install --frozen-lockfile |
Yes (4.3.4) |
✅ (blocked) |
| 5d |
Manual package.json edit |
pnpm install --lockfile-only |
Yes (4.3.4) |
✅ (blocked) |
| 6a |
Lockfile already contains violating version |
pnpm install |
Yes (4.3.5) |
❌ |
| 6b |
Lockfile already contains violating version |
pnpm install --fix-lockfile |
Yes (4.3.5) |
❌ |
| 6c |
Lockfile already contains violating version |
pnpm install --frozen-lockfile |
Yes (4.3.5) |
❌ |
| 6d |
Lockfile already contains violating version |
pnpm install --lockfile-only |
Yes (4.3.5) |
❌ |
Legend
- ✅ = Works as expected, command respects
minimumReleaseAge
- ❌ = Bug, command does not respect
minimumReleaseAge
Test scenarios
Click to expand
The library I'm testing with is zod, where the version 4.3.4 is older than the configured minimumReleaseAge, and version 4.3.5 is newer than the configured minimumReleaseAge and thus is invalid.
Test scenario 1: dependency doesn't exist in lockfile, and I try to install a version that violates the minimumReleaseAge
- I run
pnpm add zod@4.3.5
- The command fails with
Version 4.3.5 (released 6 days ago) of zod does not meet the minimumReleaseAge constraint ✅
Test scenario 2: dependency exists in lockfile (4.3.5), and I try to reinstall the same version that violates the minimumReleaseAge
zod@4.3.5 is already installed (present in pnpm-lock.yaml)- I try to reinstall the same
zod version 4.3.5 using pnpm add zod@4.3.5
- The command completes successfully, and
zod@4.3.5 remains installed ❌
Test scenario 3: dependency exists in lockfile, and I try to upgrade it to the latest version (would violate the minimumReleaseAge)
zod@4.3.4 is already installed (present in pnpm-lock.yaml)- I try to upgrade
zod to version 4.3.5 using pnpm add zod@latest
zod version does not get upgraded, because 4.3.5 is newer than the configured minimumReleaseAge ✅
Test scenario 4: dependency exists in lockfile (4.3.4), and I try to upgrade it to a version that violates the minimumReleaseAge
zod@4.3.4 is already installed (present in pnpm-lock.yaml)- I try to upgrade
zod to version 4.3.5 using pnpm add zod@4.3.5
- The command fails with
Version 4.3.5 (released 6 days ago) of zod does not meet the minimumReleaseAge constraint ✅
Test scenario 5: dependency exists in lockfile, and I try to upgrade it to a version that violates the minimumReleaseAge
zod@4.3.4 is already installed (present in pnpm-lock.yaml)- I try to upgrade
zod to version 4.3.5 by manually editing package.json, and then run:
pnpm install: correctly fails with Version 4.3.5 (released 6 days ago) of zod does not meet the minimumReleaseAge constraint ✅pnpm install --fix-lockfile: correctly fails with Version 4.3.5 (released 6 days ago) of zod does not meet the minimumReleaseAge constraint ✅pnpm install --frozen-lockfile: correctly fails with ERR_PNPM_OUTDATED_LOCKFILE Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with <ROOT>\package.json ✅pnpm install --lockfile-only: correctly fails with Version 4.3.5 (released 6 days ago) of zod does not meet the minimumReleaseAge constraint ✅
Test scenario 6: run pmpn install where the lockfile has a version that violates minimumReleaseAge
- Temporarily remove
minimumReleaseAge from pnpm-workspace.yaml
- Install a version that violates the
minimumReleaseAge using pnpm add zod@4.3.5
- Re-add
minimumReleaseAge to pnpm-workspace.yaml and then run:
pnpm install: gladly completes even though there's a version that violates minimumReleaseAge ❌pnpm install --fix-lockfile: gladly completes even though there's a version that violates minimumReleaseAge ❌pnpm install --frozen-lockfile: gladly completes even though there's a version that violates minimumReleaseAge ❌pnpm install --lockfile-only: gladly completes even though there's a version that violates minimumReleaseAge ❌
Expected Behavior
I believe the minimumReleaseAge constraint should be validated during all install operations, including when dependencies already exist in the lockfile. Specifically:
pnpm add should fail with an error when trying to add a version that violates minimumReleaseAge, regardless of whether the lockfile already contains that specific version or notpnpm install should fail with an error when the lockfile contains versions that violate minimumReleaseAgepnpm install --fix-lockfile should fail with an error when the lockfile contains versions that violate minimumReleaseAgepnpm install --frozen-lockfile should fail with an error when the lockfile contains versions that violate minimumReleaseAgepnpm install --lockfile-only should fail with an error when the lockfile contains versions that violate minimumReleaseAge
This would ensure consistent security posture and prevent scenarios where teams enable minimumReleaseAge but continue using recently-released (and potentially vulnerable) versions that were installed before the constraint was added.
Motivation for Fixing the Bug
This is a very frequent scenario for folks migrating to pnpm from other package managers - this is exactly what happened with my at the company I work for, we migrated from yarn to pnpm and a few days later we learned about pnpm's security measures against supply chain attacks, so we enabled all the options including minimumReleaseAge right away to enhance our security.
However, since our pnpm-lock.yaml already contained some dependencies that violated the minimumReleaseAge, we were effectively not protected by this configuration after enabling it until we accidentally changed zod version in one of our projects, then found out about this bug.
Conclusion
Fixing this bug would ensure that teams adopting pnpm can immediately benefit from the security features without worrying about existing lockfile entries bypassing the intended protections. I would personally love to get immediate feedback after enabling minimumReleaseAge that some of our dependencies are too new, so we can take action to remediate the issue right away - and not what pnpm is doing right now, which is to silently allow the installation of violating versions if they already exist in the lockfile.
AI analysis
I took the initiative and ran an AI analysis (using Claude Opus 4.5) on the issue description to see if it could provide any additional insights.
Here is the its analysis results, and feel free to disregard it entirely if you find it unhelpful: MINIMUM_RELEASE_AGE_BUG_ANALYSIS.md
Which Node.js version are you using?
22.21.1
Which operating systems have you used?
If your OS is a Linux based, which one it is? (Include the version if relevant)
No response
Verify latest release
pnpm version
No response
Which area(s) of pnpm are affected? (leave empty if unsure)
No response
Describe the Bug
The
minimumReleaseAgeconfiguration option is not enforced when runningpnpm install(or its variants with--fix-lockfile,--frozen-lockfile,--lockfile-only) if the lockfile already contains a dependency version that violates the constraint. This means that once a violating version is present inpnpm-lock.yaml, pnpm allows installation to proceed without validation, effectively bypassing theminimumReleaseAgeprotection.This behavior is inconsistent with other security-related flags like
strictDepBuilds, which validates configuration constraints regardless of whether dependencies existed in the lockfile before the flag was enabled.Reproduction steps
I conducted tests to see in what scenarios
pnpmdidn't behave as expected, and their reproduction steps are outlined in their respective test scenario.Test Environment
OS: Windows 11 (version 25H2 build 26200.7462)
pnpm version: 10.27.0
Test package:
zod4.3.4: Older thanminimumReleaseAge✅4.3.5: Newer thanminimumReleaseAge❌Configuration:
Table summarizing test cases and results
minimumReleaseAgepnpm add zod@4.3.5pnpm add zod@4.3.5none)pnpm add zod@4.3.54.3.5)pnpm add zod@latest4.3.4)pnpm add zod@4.3.54.3.4)pnpm install4.3.4)pnpm install --fix-lockfile4.3.4)pnpm install --frozen-lockfile4.3.4)pnpm install --lockfile-only4.3.4)pnpm install4.3.5)pnpm install --fix-lockfile4.3.5)pnpm install --frozen-lockfile4.3.5)pnpm install --lockfile-only4.3.5)Legend
minimumReleaseAgeminimumReleaseAgeTest scenarios
Click to expand
The library I'm testing with is
zod, where the version4.3.4is older than the configuredminimumReleaseAge, and version4.3.5is newer than the configuredminimumReleaseAgeand thus is invalid.Test scenario 1: dependency doesn't exist in lockfile, and I try to install a version that violates the
minimumReleaseAgepnpm add zod@4.3.5Version 4.3.5 (released 6 days ago) of zod does not meet the minimumReleaseAge constraint✅Test scenario 2: dependency exists in lockfile (4.3.5), and I try to reinstall the same version that violates the
minimumReleaseAgezod@4.3.5is already installed (present inpnpm-lock.yaml)zodversion4.3.5usingpnpm add zod@4.3.5zod@4.3.5remains installed ❌Test scenario 3: dependency exists in lockfile, and I try to upgrade it to the latest version (would violate the
minimumReleaseAge)zod@4.3.4is already installed (present inpnpm-lock.yaml)zodto version4.3.5usingpnpm add zod@latestzodversion does not get upgraded, because4.3.5is newer than the configuredminimumReleaseAge✅Test scenario 4: dependency exists in lockfile (4.3.4), and I try to upgrade it to a version that violates the
minimumReleaseAgezod@4.3.4is already installed (present inpnpm-lock.yaml)zodto version4.3.5usingpnpm add zod@4.3.5Version 4.3.5 (released 6 days ago) of zod does not meet the minimumReleaseAge constraint✅Test scenario 5: dependency exists in lockfile, and I try to upgrade it to a version that violates the
minimumReleaseAgezod@4.3.4is already installed (present inpnpm-lock.yaml)zodto version4.3.5by manually editingpackage.json, and then run:pnpm install: correctly fails withVersion 4.3.5 (released 6 days ago) of zod does not meet the minimumReleaseAge constraint✅pnpm install --fix-lockfile: correctly fails withVersion 4.3.5 (released 6 days ago) of zod does not meet the minimumReleaseAge constraint✅pnpm install --frozen-lockfile: correctly fails withERR_PNPM_OUTDATED_LOCKFILE Cannot install with "frozen-lockfile" because pnpm-lock.yaml is not up to date with <ROOT>\package.json✅pnpm install --lockfile-only: correctly fails withVersion 4.3.5 (released 6 days ago) of zod does not meet the minimumReleaseAge constraint✅Test scenario 6: run
pmpn installwhere the lockfile has a version that violatesminimumReleaseAgeminimumReleaseAgefrompnpm-workspace.yamlminimumReleaseAgeusingpnpm add zod@4.3.5minimumReleaseAgetopnpm-workspace.yamland then run:pnpm install: gladly completes even though there's a version that violatesminimumReleaseAge❌pnpm install --fix-lockfile: gladly completes even though there's a version that violatesminimumReleaseAge❌pnpm install --frozen-lockfile: gladly completes even though there's a version that violatesminimumReleaseAge❌pnpm install --lockfile-only: gladly completes even though there's a version that violatesminimumReleaseAge❌Expected Behavior
I believe the
minimumReleaseAgeconstraint should be validated during all install operations, including when dependencies already exist in the lockfile. Specifically:pnpm addshould fail with an error when trying to add a version that violatesminimumReleaseAge, regardless of whether the lockfile already contains that specific version or notpnpm installshould fail with an error when the lockfile contains versions that violateminimumReleaseAgepnpm install --fix-lockfileshould fail with an error when the lockfile contains versions that violateminimumReleaseAgepnpm install --frozen-lockfileshould fail with an error when the lockfile contains versions that violateminimumReleaseAgepnpm install --lockfile-onlyshould fail with an error when the lockfile contains versions that violateminimumReleaseAgeThis would ensure consistent security posture and prevent scenarios where teams enable
minimumReleaseAgebut continue using recently-released (and potentially vulnerable) versions that were installed before the constraint was added.Motivation for Fixing the Bug
This is a very frequent scenario for folks migrating to
pnpmfrom other package managers - this is exactly what happened with my at the company I work for, we migrated fromyarntopnpmand a few days later we learned about pnpm's security measures against supply chain attacks, so we enabled all the options includingminimumReleaseAgeright away to enhance our security.However, since our
pnpm-lock.yamlalready contained some dependencies that violated theminimumReleaseAge, we were effectively not protected by this configuration after enabling it until we accidentally changedzodversion in one of our projects, then found out about this bug.Conclusion
Fixing this bug would ensure that teams adopting
pnpmcan immediately benefit from the security features without worrying about existing lockfile entries bypassing the intended protections. I would personally love to get immediate feedback after enablingminimumReleaseAgethat some of our dependencies are too new, so we can take action to remediate the issue right away - and not whatpnpmis doing right now, which is to silently allow the installation of violating versions if they already exist in the lockfile.AI analysis
I took the initiative and ran an AI analysis (using Claude Opus 4.5) on the issue description to see if it could provide any additional insights.
Here is the its analysis results, and feel free to disregard it entirely if you find it unhelpful: MINIMUM_RELEASE_AGE_BUG_ANALYSIS.md
Which Node.js version are you using?
22.21.1
Which operating systems have you used?
If your OS is a Linux based, which one it is? (Include the version if relevant)
No response