Add package exclusion support for min-release-age

[camelmasa]

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?

[yeikel]

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/*"

[camelmasa]

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.

[camelmasa]

@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.

[jnloureiro]

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.

[SchroederSteffen]

Related:

• (FR): Implement exclusion mechanism for 'minimumReleaseAge' feature for CVE mitigation #8979 (comment)

[BruceHubbard]

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.

[nikwen]

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