Add package exclusion support for min-release-age

@yeikel

Summary

With min-release-age now available (#8965), there is a common workflow that remains unsupported: applying a strict release age policy for third-party dependencies while allowing immediate updates for internally maintained packages.

This was originally proposed as part of #8825 (minimum-release-age-exclude), but was not carried forward into #8965, which focused on solving one problem at a time.

Motivation

As @yeikel noted in #8965 (comment):

From the diff, it seems the decision was made not to allow excluding packages. That's fine, but it does conflict with a common workflow: being strict with third-party dependencies while remaining more lenient with internally maintained packages.

@wraithgar acknowledged this as a separate concern:

Excluding packages is wholly separate from this new parameter. It was excluded in the interest of solving one problem at a time.

This issue is intended to track that next step and continue the discussion from #8825.

Use case

Organizations that publish internal packages (e.g., @myorg/shared-utils) often need to deploy updates immediately, while still wanting the safety net of min-release-age for external dependencies. Without an exclusion mechanism, adopting min-release-age means either applying it uniformly (blocking internal updates) or not using it at all.

Prior art

PR feat: add minimum package age policy to prevent supply chain attacks #8825 proposed minimum-release-age-exclude as an array of package names
pnpm's minimumReleaseAge was the original inspiration (Add a way to enforce a minimum package age policy pnpm/pnpm#9921)

Open questions

Naming: min-release-age-exclude to align with the merged config, or another convention?
Should it support glob patterns (e.g., @myorg/*) or exact package names only?
Any other considerations from the npm team?

Some thoughts:

min-release-age-exclude sounds reasonable to me
Should it support glob patterns:

To stay consistent with other package managers, we should likely support glob patterns. Whether we include that in the initial release or address it in a follow-up is something we can decide.

The following package managers implemented glob patterns:

pnpm

minimumReleaseAge: 1440
minimumReleaseAgeExclude:
- '@myorg/*'

Yarn

npmMinimalAgeGate: 4320 # 3 days (in minutes)
npmPreapprovedPackages:
  - '@myorg/*'

Dependabot (not exactly a package manager but it is worth mentioning)

  cooldown:
    default-days: 4
    exclude:
      - "@myorg/*"

@yeikel

Thanks for the thorough research, @yeikel.

I agree that glob pattern support (e.g., @myorg/*) makes sense — it's clearly the standard across pnpm, Yarn, and Dependabot.

Whether to include glob support in the initial release or as a follow-up is something I'd leave to the maintainers to decide based on their roadmap and priorities.

@wraithgar

@wraithgar Would love to hear your thoughts on this when you get a chance. You mentioned in #8965 that excluding packages is separate — this issue is meant to track that next step. Any guidance on direction would be appreciated.

npm already offers syntax for this use case in the form of @myorg:registry=..., though it only seems to be functional for registry configuration. Maybe it could be used here as well?

Additionally, would this option only limit the scoped packages themselves or would it also limit all of their dependencies?
A scoped package with a third-party dependency that's more recent than the configured minimum age would potentially compromise the security this feature intends to offer. If, instead, third-party dependencies of scoped packages must obey the minimum age configuration, conflicts may arise with the dependency versions declared by the package.

(FR): Implement exclusion mechanism for 'minimumReleaseAge' feature for CVE mitigation rfcs#895 (comment)

Without having a mechanism to exclude certain packages min-release-age is not nearly as useful as it could be. What happens when a security vulnerability comes in and a particular package needs to be updated? What would the process be? Do we basically have to:

remove min-release-age
update the package
Wait n days and then reintroduce min-release-age

That would leave us vulnerable for those n days and would require 2 PR's. How are those that are using min-release-age handling it when you need to update a package that is <n days old? That is definitely a scenario that is going to happen.

Wait n days and then reintroduce min-release-age

I just tested. This part is not necessary.

This works:

remove min-release-age
update the package
reintroduce min-release-age

@nikwen

@nikwen Thanks! I'm guessing after your remove min-release-age and then update the package it is adding the package to the lock file. Does that mean that npm will install packages less than n days old as long as it is in the lock file? Or is this because you had the package cached locally? I don't want to do this locally and then have it fail in a pipeline where that package isn't cached.

@BruceHubbard

@BruceHubbard Yes, it seems to be because it modifies the lockfile. Running npm install on a computer that didn't have the package cached worked fine.

@nikwen Thanks! I'm guessing after your remove min-release-age and then update the package it is adding the package to the lock file. Does that mean that npm will install packages less than n days old as long as it is in the lock file? Or is this because you had the package cached locally? I don't want to do this locally and then have it fail in a pipeline where that package isn't cached.

As far as I understand - if you are not utilizing lockfiles (do not use npm ci and just run npm install for example) you will have the same problem in CI.

Is that correct?

Wait n days and then reintroduce min-release-age

I just tested. This part is not necessary.

This works:

remove min-release-age

update the package

reintroduce min-release-age

I think npm install sax --min-release-age=0 is a bit cleaner way

@nikwen

@nikwen OK that's great! I guess I incorrectly thought that even if the package was in the lock file that if it was less than n days old it still wouldn't install the package but this works for me.

As far as I understand - if you are not utilizing lockfiles (do not use npm ci and just run npm install for example) you will have the same problem in CI.

Is that correct?

No, in the simple case (no changes to package.json) npm install also uses the lock file.

The best current approach appears to be:

Add min-release-age=X to .npmrc
When in need of a newer version of a specific package, pass --min-release-age=0 to i.e. npm install or npm update.

Consequences:

The pinned newer version in package-lock.json will work fine for both npm install and npm ci on other clients.
Only real problem is that as part of that npm install @acme/pkg --min-release-age=0 bypass command, you will also get the very latest versions of all dependencies pulled in by that package. This is what min-release-age-exclude should help with.

sigh

Can this be moved up in priority now?

With the current increase in supply chain attacks having the min age flag is very important but at the same time this blocks installing private packages, we need this exclusion flag supported asap please.

fix(cooldown): correct per-PM native config keys + real --check enfor…

fix(cooldown): hook stays engaged on npm for the allowlist; never --b…

docs(cooldown): correct per-PM keys/units, document npm-no-exclude; b…

feat(npm,pnpm): add supply-chain release-age embargo

feat(npm,pnpm): add release-age embargo to user npmrc

As far as I can tell, it is blocked by npm/rfcs#868, so head over there and contribute, if you want it resolved faster.

The comment that lead me there #9175 (comment), and then npm/rfcs#861 (comment)

npm already offers syntax for this use case in the form of @myorg:registry=..., though it only seems to be functional for registry configuration. Maybe it could be used here as well?

I.e. you could just bring that idea full circle as:

min-release-age=3
@myorg:min-release-age=0

This seems insanely more simple than any kind of custom exclusion list syntax.

@myorg

npm already offers syntax for this use case in the form of @myorg:registry=..., though it only seems to be functional for registry configuration. Maybe it could be used here as well?

I.e. you could just bring that idea full circle as:
min-release-age=3
@myorg:min-release-age=0
This seems insanely more simple than any kind of custom exclusion list syntax.

This would make sense, since you should also have to add configuration to limit your @myorg to your private repo as well. Otherwise, people could clone your internal project name and upload a compromised version with a newer version to a public repo, and together with your exclusion, you would still pull the compromised version from the public repo.

@myorg

This would make sense, since you should also have to add configuration to limit your @myorg to your private repo as well. Otherwise, people could clone your internal project name and upload a compromised version with a newer version to a public repo, and together with your exclusion, you would still pull the compromised version from the public repo.

You should always own your private scope in the public registry, even if you don't actually publish any packages into it. You never want to let someone else upload a version with the same name.

Hey guys, any update on when this will be worked on? Is it possible to move this up in priority?

feat(cooldown): emit documenting header naming the own-scope override…

chore(install): exempt first-party @claxedo/* from release-age cooldown

Support npm in gestate trust via min-release-age-exclude (npm >= 11.1…

Wait n days and then reintroduce min-release-age

I just tested. This part is not necessary.

This works:

remove min-release-age

update the package

reintroduce min-release-age

negative side effects:

obvious one: other top level dependencies (not transient) are updated that should not be updated.
this would also update public third party transient dependencies according to ^ ~ notation.
I want to update myCompany@myPackage from 1.0.0 to 1.0.1 because i changed some code but did not chance any dependencies. I dont want that this update also updates a transient dependency like express from 4.22.1 to 4.22.1 because it is set to express: ~4.22.0 by a package used by myCompany@myPackage.

example dependencies tree:

app 2.0.0
├─ myCompany@myPackage "1.0.1"
      ├─ aPublicPackage "3.0.0"
      ├─ bPublicPackage "5.0.0"
               ├─ express "~4.22.0"

Navigation Menu

Repository navigation

Add package exclusion support for min-release-age #8994

Summary

Motivation

Use case

Prior art

Open questions

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add package exclusion support for min-release-age #8994

Description

Summary

Motivation

Use case

Prior art

Open questions

Activity

yeikel commented on Feb 19, 2026

camelmasa commented on Feb 20, 2026

camelmasa commented on Feb 21, 2026

jnloureiro commented on Mar 9, 2026

SchroederSteffen commented on Mar 27, 2026

BruceHubbard commented on Apr 17, 2026

nikwen commented on May 1, 2026

BruceHubbard commented on May 1, 2026

nikwen commented on May 1, 2026

Bafff commented on May 1, 2026

Bafff commented on May 1, 2026

BruceHubbard commented on May 1, 2026

mikkelblanne commented on May 4, 2026

dwolrdcojp commented on May 13, 2026

rouse-bruno-favero commented on May 13, 2026

runephilosof-abtion commented on May 18, 2026

rjgotten commented on May 19, 2026

wanjakrah commented on May 19, 2026

jamie-tm commented on May 19, 2026

Ashwin2397 commented on Jun 6, 2026

grafanauser commented on Aug 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions