Add minimumReleaseAgeTrustedVersions instead of minimumReleaseAgeExclude.

[igalklebanov]

Hey 👋

Thanks for this awesome package manager and all the effort put into helping secure javascript development! ❤️

I find "excludes" and "allows" like minimumReleaseAgeExclude dangerous.

People tend to forget to remove these configurations - especially in day job monorepos.

Scenario:

1/1/2026 - your teammate bumped to pnpm 10.16.x and added the shiny new minimumReleaseAge configuration and set it to 24 hours.
3/1/2026 - you install @helloworld/console and put it in minimumReleaseAgeExclude because you wanted the latest version that was released 5 hours ago - it fixes some bug you were waiting for. you don't add it to overrides or catalog it.
4/1/2026 - feature work is done, and you move on. you forgot to remove @helloworld/console from minimumReleaseAgeExclude.
4/3/2026 12:05 - @helloworld/console gets hacked. malicious version are published to NPM for patch, minor and major.
4/3/2026 14:15 - a teammate needs to work on a new monorepo package. he installs @helloworld/console, seeing that you've used it in another package and it looks slick - and it's from the helloworld team. the package manager chooses the latest version, despite being published only ~2 hours ago.

Suggestion:

add minimumReleaseAgeTrustedVersions, which works like minimumReleaseAgeExclude but only for specific exact version/s of a library.

Something like:

minimumReleaseAgeTrustedVersions:
  '@helloworld/console': ['1.2.3']

[igalklebanov]

Similarly, there could be onlyBuiltDependenciesTrustedVersions, this'll help in the nx scenario - where a good postinstall was replaced with a bad postinstall.

[karlhorky]

@igalklebanov there is an issue to extend minimumReleaseAgeExclude to also support version numbers:

• minimumReleaseAgeExclude: Add support for version range #9985

It's not exactly the same as your proposal above, but I think it achieves pretty much the same thing.