fix: allow min-release-age in npmrc to coexist with --before in spawn…#9292
Open
raazkhnl wants to merge 1 commit intonpm:latestfrom
Open
fix: allow min-release-age in npmrc to coexist with --before in spawn…#9292raazkhnl wants to merge 1 commit intonpm:latestfrom
raazkhnl wants to merge 1 commit intonpm:latestfrom
Conversation
owlstronaut
requested changes
May 1, 2026
Contributor
owlstronaut
left a comment
There was a problem hiding this comment.
Thanks for digging in to this! The fix for the spawn case seems to work great. I'm concerned about the flatten changing precedence though. min-release-age now effectively can't be relaxed by a higher priority source. so npm i --min-release-age=0 will silently get ignored if .npmrc is stricter. I think the PR just needs to be narrowed a bit
…ed subprocesses When the user has `min-release-age=N` in their `.npmrc`, the config flatten function derives a `before` date used by pacote. Whenever pacote spawns a child npm process (e.g. preparing a `git:` or `github:` dep), it forwards `--before=<date>` to the child. The child then loads the same `.npmrc` and the previously declared mutual-exclusivity between `before` and `min-release-age` caused a hard configuration error. This makes the two options coexist: the `exclusive` constraints are removed and both flatten functions resolve to the earlier of the two effective dates, never widening the user's most conservative bound. The `min-release-age` flatten no longer mutates the per-source config object (the prior `obj.before = ...` / `delete obj['min-release-age']` mutations were vestigial and only masked the conflict at the parent level, not in spawned children). `min-release-age` is also added to the `params` arrays for `outdated` and `update` so it remains visible in their command help; it was previously displayed implicitly via the `before` exclusive grouping. Fixes: npm#9291
9a10258 to
8daf473
Compare
owlstronaut
requested changes
May 4, 2026
| // absolute date overrides a relative window. Across sources, normal | ||
| // priority ordering means a higher-priority `before` will overwrite | ||
| // this `flatOptions.before` later in the flatten loop. | ||
| if (obj['min-release-age'] != null && obj.before == null) { |
Contributor
There was a problem hiding this comment.
Suggested change
| if (obj['min-release-age'] != null && obj.before == null) { | |
| if (obj['min-release-age'] != null && !Object.hasOwn(obj, 'before')) { |
this will scope it to the current source so the CLI/env can still override an npmrc-set before
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…ed subprocesses
When the user has
min-release-age=Nin their.npmrc, the config flatten function derives abeforedate used by pacote. Whenever pacote spawns a child npm process (e.g. preparing agit:orgithub:dep), it forwards--before=<date>to the child. The child then loads the same.npmrcand the previously declared mutual-exclusivity betweenbeforeandmin-release-agecaused a hard configuration error.This makes the two options coexist: the
exclusiveconstraints are removed and both flatten functions resolve to the earlier of the two effective dates, never widening the user's most conservative bound. Themin-release-ageflatten no longer mutates the per-source config object (the priorobj.before = .../delete obj['min-release-age']mutations were vestigial and only masked the conflict at the parent level, not in spawned children).min-release-ageis also added to theparamsarrays foroutdatedandupdateso it remains visible in their command help; it was previously displayed implicitly via thebeforeexclusive grouping.Fixes: #9291