Repository navigation
fix: honor semver prerelease rules in version resolution - #906
Open
Aschenbath wants to merge 2 commits into
Open
Aschenbath wants to merge 2 commits into
Aschenbath wants to merge 2 commits into
Conversation
Signed-off-by: Nash Aschenbath <wwh86696@163.com>
Signed-off-by: Nash Aschenbath <wwh86696@163.com>
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
1 participant
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.
A range such as
pnpm@9can select9.1.0-0, andcorepack upcan move a stable project onto that prerelease. Registry resolution currently removes prerelease components while testing ranges; it also accepts a prerelease below an explicitly requested prerelease lower bound.Use semver's standard range matcher for registry candidates, consistent with cache lookup. Exact prerelease versions, tags, and ranges that explicitly include prereleases remain supported. When the version selected by
corepack upis a prerelease, keep that version as the lower bound within its major release line. This permits newer prereleases with the same major/minor/patch numbers and newer stable releases, without downgrading to an older stable version.Package-manager configuration lookup retains its existing matcher so that explicitly selected development releases still resolve their binary layout correctly. The README describes registry range and upgrade behavior.
Fixes #473.
Fixes #774.
Validation on Node.js 22.23.3 in WSL:
corepack yarn build,corepack yarn typecheck, andcorepack yarn lint --max-warnings=0passed.NOCK_ENV=replay corepack yarn test run --retry=0: 185 passed and one existing expected failure across nine files.use, global installation andup; explicit prerelease versions/ranges/tags; prerelease upgrades and promotion to stable; and rejection of out-of-range versions or downgrades. Rejected requests leave the manifest unchanged.fc545280df617b575dba235206c43d3d43d50ed1: static checks and Node.js 22/24/26 across Linux, macOS, and Windows. All nine platform jobs ran and passed the fourteen prerelease regressions. The upstream workflow is awaiting maintainer approval.The registry fixture serves opt-in prerelease versions and parses tarball names containing prerelease hyphens. Its ordinary version lists and signature checks remain in place. The full suite also passes the existing pnpm development-release binary-layout tests.
Implementation and automated validation were performed by Codex.