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?