fix: release devtools as minor, not patch - #1159
Open
abhithesys wants to merge 3 commits into
Open
Conversation
- release.yml: create the Version Packages PR with a token minted from the THESYS_PR_CREATOR GitHub App (vars.THESYS_PR_CREATOR_APP_ID + secrets.THESYS_PR_CREATOR_PRIVATE_KEY). GITHUB_TOKEN is not permitted to create PRs in this org, so every Release run has been failing at PR creation; app-made pushes and PRs also trigger workflows, giving the Version PR normal CI. Token goes to the action's github-token input (v2) and to env GITHUB_TOKEN for @changesets/changelog-github lookups; workflow permissions drop to contents:read + id-token:write. - cli-e2e.yml: the pnpm matrix step's explicit version collides with the root packageManager field (action-setup v6 hard-errors on the mismatch); point package_json_file at packages/openui-cli/package.json so the matrix version stays authoritative for template testing. Requires the app var/secret to be configured on the repo before the next Release run can succeed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Inside the checkout, pnpm >=10 self-switches to the root packageManager version (pnpm@10.33.0) and reports it, failing the matrix expectation (Expected pnpm 11.x, got 10.33.0). The e2e steps all run under runner.temp, so verify there — measuring the pnpm the templates will actually use. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
react-lang 0.2.x depends on devtools ^0.1.0, so a devtools 0.1.x release carrying the new peer requirement (react-lang >=0.3.0) would be pulled into existing react-lang 0.2.x installs and break them with an unsatisfiable peer at install time. Releasing 0.2.0 instead escapes ^0.1.0: old react-lang keeps resolving old devtools, and only react-lang >=0.3.0 (released in the same train, depending on devtools ^0.2.0) picks up the new line. Same reasoning as react-email's minor in the original release-automation PR. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
AbhinRustagi
force-pushed
the
abhishek/devtools-changeset-minor
branch
from
September 11, 2026 05:50
bf81e70 to
f433a0e
Compare
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.
react-lang 0.2.x depends on devtools ^0.1.0, so a devtools 0.1.x release carrying the new peer requirement (react-lang >=0.3.0) would be pulled into existing react-lang 0.2.x installs and break them with an unsatisfiable peer at install time. Releasing 0.2.0 instead escapes ^0.1.0: old react-lang keeps resolving old devtools, and only react-lang >=0.3.0 (released in the same train, depending on devtools ^0.2.0) picks up the new line. Same reasoning as react-email's minor in the original release-automation PR.