Repository navigation
fix(@angular/cli): respect min-release-age during version resolution - #33278
Closed
crimsondhaks wants to merge 2 commits into
Closed
crimsondhaks wants to merge 2 commits into
crimsondhaks wants to merge 2 commits into
Conversation
When a project configures a minimum release age cooldown via the package manager (npm `min-release-age`, pnpm 10.x `minimum-release-age`), the CLI must exclude versions younger than the cooldown from automatic version selection. Otherwise `ng update` and `ng add` pick a version that the package manager subsequently refuses to install, surfacing as `Process exited with code 1` or `ETARGET`. `PackageManager.getManifest` now reads the cooldown from `.npmrc` and filters candidate versions accordingly when resolving `tag`/`range`/ `version` specifiers. When no cooldown is configured (the existing default), behavior is unchanged and no extra registry calls are made. When a tag points at a too-new version, the CLI falls back to the newest version that satisfies the cooldown so commands continue to make progress. For an explicit version that is too new, the lookup returns null, mirroring what the package manager itself would do. Fixes angular#33119
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces support for respecting the user-configured 'minimum release age' (install cooldown) from package managers during automatic version selection. The feedback suggests optimizing the implementation by bypassing registry metadata fetches and cooldown checks when an explicit version is requested, preserving pre-release preferences during tag fallback, updating corresponding unit tests, and improving repository root detection to support git submodules and worktrees.
Follow-up to the previous commit, addressing review feedback. - Skip the metadata fetch for explicit version specifiers when a cooldown is configured. The package manager itself enforces the cooldown at install time, and an extra registry round-trip just slows down the common case (`ng add foo@1.2.3`). - Pass `includePrerelease: true` to `maxSatisfying` on the tag fallback path so `next` does not silently downgrade to a stable release when its current pointer is too new. - Detect a `.git` repo root by existence rather than `isDirectory()` so the `.npmrc` walk also stops at submodule and worktree roots, where `.git` is a regular file containing a `gitdir:` pointer. New unit tests cover the prerelease fallback and the gitfile case.
Author
|
Thanks for the review — all three points addressed in the follow-up commit:
200 specs pass locally; lint and prettier clean. |
Collaborator
|
Thanks for this, but this is being tackled via #33364 |
|
This pull request has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Fixes #33119.
If you set
min-release-age(npm) orminimum-release-age(pnpm 10.x) in.npmrc,ng updateandng addblow up because the CLI happily picks the newest version off the registry, then the package manager refuses to install it. You getProcess exited with code 1from update andETARGETfrom add.The fix: when a cooldown is configured,
PackageManager.getManifestfilters candidate versions by the registry'stimefield before picking one. For ataglikelatest, if the resolved version is too new it falls back to the newest one that's old enough so the command can still finish. For an explicit version that's too new, it returnsnull(same as the package manager would).If no cooldown is configured, nothing changes — no extra registry calls, same behavior as before.
Not covered yet (left for follow-ups since the configs live elsewhere): pnpm 11+
minimumReleaseAgeinpnpm-workspace.yaml, yarn berrynpmMinimalAgeGatein.yarnrc.yml, buninstall.minimumReleaseAgeinbunfig.toml.Tests: added unit coverage in
min-release-age_spec.tsandpackage-manager_spec.ts.pnpm bazel test //packages/angular/cli:testpasses (198 specs). Lint and prettier clean.