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.