fix(ci): version-contract guard no longer reads a first publish as a tightening - #2983
Merged
Conversation
…tightening A package that is `private: true` at the base has never been published. It has no consumer and no prior contract, so its first publish *establishes* the engines.node floor and the peer ranges — it cannot tighten them. Without this, going `private: true` -> public while adding `engines.node` reported `(none) -> >=24.0.0` and demanded a breaking marker. Neither remedy the guard offered was available: a breaking marker is rejected on `next` by the routing job in the same workflow, and reverting means publishing a CLI with no Node floor. `collectFindings` already skipped a package with no base file at all, for exactly this reason. The gap was the case in between: the package existed at the base but was not publishable. Two tests. The second pins that the rule is not switched off — an already-published package gaining `engines.node` still flags. Closes #2980 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
Coverage Report for ./packages/components/
File CoverageNo changed files found. |
Contributor
🚀 Preview DeploymentPreview environments are ready:
Images:
|
Lisa18289
approved these changes
Aug 28, 2026
mfal
added a commit
that referenced
this pull request
Aug 28, 2026
…ivers it
Takes .github/scripts/version-contract-lib{,.test}.mjs verbatim from `main`,
where #2983 fixed the guard reading a package's first publish as a tightening.
This PR's version-contract check runs the script from its own tree, so it
cannot pass until that fix is present here. The cascade would normally supply
it, but the forward-merge is stuck on a pnpm-lock.yaml conflict and the sync PR
resolving it (#2981) predates the fix and has a red visual suite of its own.
Byte-identical to `main` on purpose: when the cascade does reach `next`, git
sees no difference and there is nothing to reconcile. Nothing is authored here
— the fix itself was reviewed and merged in #2983.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.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
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.
What & why
A package that is
private: trueat the base has never been published. It has no consumer and no prior contract, so its first publish establishes theengines.nodefloor and the peer ranges — it cannot tighten them.Without this, going
private: true→ public while addingengines.nodereported:Neither remedy the guard offered was available. A breaking marker is rejected on
nextby theroutingjob in the same workflow, so the two guards contradicted each other. And reverting the "tightening" means publishing a CLI with no Node floor while all twelve already-published packages declare one.collectFindingsalready skipped a package with no base file at all, for exactly this reason. The gap was the case in between: the package existed at the base but was not publishable.The fix is one guard clause plus its rationale, right after the existing
if (!base) continue:Closes #2980. Unblocks #2978, whose version-contract check fails until this lands — the fix was on that branch and was reverted out of it, since CI infrastructure does not belong in a codemods feature PR and this repo squash-merges.
Notes for the reviewer
collectFindings: a published package gaining engines.node still flagspins that the rule is not being switched off — an already-published package adding a floor still produces oneengines.node/raisedfinding. Written test-first and confirmed red before the fix.fix(ci):→ basemain. feat(codemods): add an upgrade CLI backed by a migration catalogue #2978 sits onnext;forward-merge.ymlmergesmainintonexton push, so it picks the fixed guard up from there.release-relevance-lib.mjsthis publishes nothing.nextexisted, so this is plausibly its first encounter with a first publish.Verification
Checklist
pnpm lintis clean andpnpm affected:testpasses (browser tests if behavior changed) — the changed files are outside the pnpm workspace; the guard's own suite is what covers them, and it runs intest.ymland incommit-guard.yml's self-test stepde-DEanden-USlocale files — n/a, no UI🤖 Generated with Claude Code