feat: add min-release-age - #8965
Conversation
b9b3bb1 to
762d8e7
Compare
|
Config does all the heavy lifting here, making sure $ # entered on feb 6 2026
$ node . config list --min-release-age=30
; "cli" config from command line options
before = "2026-01-07T17:45:11.360Z"We will probably want to add a specific test so that we are sure that the relative calculation works as expected, but that can come after we get a quick check from those involved in the discussion. |
ab6aef0 to
55238af
Compare
55238af to
9c3e965
Compare
|
IF YOU WOULD LIKE CREDIT for helping with this please comment in this issue to be added to the credit list. I did not write this alone. |
Would like to be contributor hahahaha Thanks for the implementation and credits @wraithgar! |
|
@PR3C14D0 you are listed as a contributor with a link to your PR already! This PR title and body will be the commit body and comment. If you would like a different link for attribution let me know. |
Right, so, everything is perfect. Thanks! |
|
Haha, was gonna look at doing the same thing when I woke up, ah timezones :) Looks great, thanks for the credit! |
|
I am late to the discussion and may have missed prior context or threads, so apologies if this has already been covered. This question comes from both curiosity and a real use case. 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. In that scenario, the lack of an exclusion option is a bit unfortunate. My understanding is that #8825 included support for this. Was there a particular reason it was ultimately not carried forward? Or will that support be added in a potential future release? |
|
Excluding packages is wholly separate from this new parameter. It was excluded in the interest of solving one problem at a time. |
Is that tracked somewhere? The reason I ask is because I think that it is a common-enough use case |
|
This should go out tomorrow, thank you everyone for helping. |
| * Type: null or Number | ||
|
|
||
| If set, npm will build the npm tree such that only versions that were | ||
| available more than the given number of days ago will be installed. If there |
There was a problem hiding this comment.
Any reason you chose "days" instead of "minutes" like pnpm?
https://pnpm.io/supply-chain-security
I was really confused when I tried this config today since the name is nearly identical but the units are different.
There was a problem hiding this comment.
Because its analog (before) was already a date, and dependabot also uses days for its similar feature.
Node 24.10.0 ships with npm 11.6.1, which fails the new engines.npm >=11.10.0 floor and silently ignores the min-release-age supply-chain gate (the option was added in npm 11.10.0 via npm/cli#8965). Add a pinned 'npm install -g npm@11.10.0' step right after each actions/setup-node so CI matches the engines declaration and the supply-chain gate is actually enforced in CI, not just locally. Also pins the existing 'Upgrade npm for OIDC support' step in publish-packages.yml from npm@latest to npm@11.10.0 for reproducibility. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
|
Out of curiosity, why was this defaulted to null? |
…cript npm 11.10.0 shipped `min-release-age` (the pnpm minimumReleaseAge equivalent), making the hand-rolled upgrade-safe.mjs redundant. - .npmrc adds `min-release-age=7` — only install versions published more than 7 days ago. Older npm versions silently ignore it. - Remove scripts/upgrade-safe.mjs - Remove the `upgrade:safe` npm script Refs: npm/cli#8965 https://docs.npmjs.com/cli/v11/using-npm/config/#min-release-age
8 participants
This is a new config that is a way to populate the "before" config using a relative date integer.
This deceptively small change was the result of a LOT of work to get to this point, primarily from these authors and PRs...
Credit:
@kaezone - #8802
@PR3C14D0 - #8825