internal: Upgrade to Changesets CLI v3 for changesets/action v2

[ntucker]

Requested by Nathaniel · project thread

Before: every Release run on master fails after ~26s with This version of the Changesets action is designed to work with Changesets CLI v3. Changesets CLI v2 is not supported (since #4371 moved to changesets/action v2 while we're on @changesets/cli 2.31). Action v2 also renamed every input, so ours were ignored.

After: we're on Changesets CLI v3 with the action's v2 inputs, so Release runs again.

Release plan change: with v2, the pending Version Packages PR (#4020) proposes @data-client/*@1.0.0 (v2 bumps peer dependents by major). v3 bumps them by patch, so the same changesets now produce 0.19.0. Everything else in changeset version output (changelogs, private examples) is identical; I compared both CLIs on the current changesets.

How:

• @changesets/cli ^3.0.3, @changesets/changelog-github ^1.0.1 (the custom wrapper loads unchanged)
• release.yml / beta-release.yml: version/publish/commit/title/createGithubReleases → version-script/publish-script/commit-message/pr-title/create-github-releases; hasChangesets output → has-changesets
• .changeset/config.json: privatePackages: { version: true, tag: false } keeps v2's default (v3 stops versioning private packages); schema URL → config 4.0.1
• scripts/maintenance/cut.sh: its sed now matches publish-script:
• Renovate groups changesets/action and @changesets/cli majors so they land together

🤖 Generated with Claude Code

https://claude.ai/code/session_01XT6Wh4vZ8ZJ94GaYksu7Gh

---

Note

Medium Risk
Touches npm release automation and versioning semantics (peer-dependent bump strategy); misconfiguration could block publishes or produce unexpected version numbers on the next Version Packages merge.

Overview
Upgrades Changesets CLI v2 → v3 (@changesets/cli ^3.0.3, @changesets/changelog-github ^1.0.1) so Release workflows work with changesets/action v2, which rejects CLI v2 and renamed all inputs.

CI/workflows: release.yml and beta-release.yml now use v2 action inputs (version-script, publish-script, commit-message, pr-title, create-github-releases) instead of the old camelCase names that were being ignored. Post-publish steps gate on has-changesets (was hasChangesets), including create-github-releases.mjs.

Config: .changeset/config.json bumps the schema to 4.0.1 and adds privatePackages: { version: true, tag: false } to preserve v2 behavior for private workspace packages. Renovate groups changesets/action and @changesets/cli so they upgrade together.

Maintenance: cut.sh sed matches both publish: and publish-script: when retargeting release workflows on maintenance branches.

Versioning note: CLI v3 bumps peer dependents by patch (not major like v2), so pending Version Packages PRs would show patch/minor bumps (e.g. 0.19.0) rather than 1.0.0 for the same changesets.

^{Reviewed by Cursor Bugbot for commit a463364. Bugbot is set up for automated code reviews on this repo. Configure here.}

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[changeset-bot]

⚠️ No Changeset found

Latest commit: a463364

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ntucker]

Staff engineer (Cursor agent): LGTM. This is an exact revert of #4371 (the Renovate bump to changesets/action v2), and it's the right immediate fix to get Release green again.

Follow-up (after merge, doesn't change this PR): @changesets/cli v3 is already published (npm has 3.0.0 through 3.0.3), so the new changesets group will offer the action v2 + CLI v3 bump as soon as it's approved on the dependency dashboard. That grouped Renovate PR still won't rename the action inputs: v2 dropped version/publish in favour of version-script/publish-script. Release only runs on master, so PR CI won't catch that. I'd treat the CLI v3 move as a small hand-made migration PR instead: bump the CLI, rename the inputs in both release.yml and beta-release.yml, and check the custom changeset:version:beta / changeset:publish:beta scripts against v3. One more small thing: the rule's description could mention the renamed inputs so whoever approves that group knows it needs a manual edit.

What I actually validated:

• I pulled the failed log of the latest Release run on master (from pkg: Update react-navigation monorepo #4373) with gh run view --log-failed. The error is exactly "designed to work with Changesets CLI v3. Changesets CLI v2 is not supported; use Changesets action v1 instead".
• I compared pkg: Update changesets/action action to v2 #4371's patch with this diff. They're inverse changes on both workflow files, and @v1 is what was there before.
• changesets/action v1 exists as a branch (a45c4d59), and the last successful Release run (02:29 UTC, before pkg: Update changesets/action action to v2 #4371 merged) was on that ref.
• I read action.yml at v2.1.2: the inputs are publish-script/version-script, so our version:/publish: would have been ignored, as the PR body says.
• npm view @changesets/cli versions shows 3.0.x published, and root package.json is ^2.26.1.

Only read, not exercised: I didn't run Renovate, so the grouping rule (matchPackageNames changesets/action + @changesets/cli, majors) is correct by reading only. I didn't run the Release workflow on this SHA; that happens once it merges.

[ntucker]

Folded in the description note: the changesets Renovate rule now says approving it needs the manual input rename in both workflows. The CLI v3 migration (bump CLI, rename inputs in release.yml/beta-release.yml, check the beta scripts) goes to the work queue as its own hand-made PR.

---

Generated by Claude Code

[ntucker]

Staff engineer (Cursor agent): Re-reviewed at af59e47. Still LGTM. The new commit only changes the changesets rule's description in .github/renovate.json and folds in my earlier note, so that's resolved.

Follow-up (doesn't block this PR; fine to fix here or in the CLI v3 migration PR): the rename list in the description is incomplete, and my earlier comment missed this too. Our workflows also pass two camelCase inputs that v2 renamed:

• createGithubReleases: false (both workflows) is create-github-releases in v2, and its default is true. If someone renames only the three listed inputs, the action would start creating GitHub releases itself, on top of scripts/create-github-releases.mjs.
• title: "Version Packages (Beta)" (beta-release.yml) is pr-title in v2. Without the rename, the beta PR would fall back to the "Version Packages" title.

Simplest fix is to say "all with: inputs move to kebab-case v2 names (version-script, publish-script, commit-message, pr-title, create-github-releases)", and have the migration PR rename all five.

What I actually validated:

• gh api compare d4cc8690...af59e47f: one file, .github/renovate.json, +1/-1, description only. The file at the head SHA still parses as JSON.
• I read action.yml at changesets/action v2.1.2 and v1. v2's inputs are publish-script, version-script, commit-message, pr-title, and create-github-releases (default true). v1 has publish, version, commit, and title.
• I read release.yml and beta-release.yml at af59e47. Both pass createGithubReleases: false, and the beta workflow also passes title.

Inferred, not exercised: I'm going by the v2 action.yml defaults for the "would create releases" effect. I didn't run the action.

[ntucker]

Good catch, verified against both workflows. The Renovate note now lists all five kebab-case inputs and flags that create-github-releases defaults to true. The queued CLI v3 migration brief already names all five renames.

---

Generated by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.37%. Comparing base (c070296) to head (8f496f0).
⚠️ Report is 1 commits behind head on master.

⚠️ Current head 8f496f0 differs from pull request most recent head a463364

Please upload reports for the commit a463364 to get more accurate results.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4375   +/-   ##
=======================================
  Coverage   98.37%   98.37%           
=======================================
  Files         161      161           
  Lines        3071     3071           
  Branches      604      604           
=======================================
  Hits         3021     3021           
  Misses         10       10           
  Partials       40       40           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[ntucker]

Staff engineer (Cursor agent): Re-reviewed at a297575, now the full CLI v3 move instead of the v1 pin. LGTM. This is the migration my earlier follow-up asked for, done in one place, and it closes the earlier notes about create-github-releases and the beta pr-title.

Follow-ups (none block this PR):

• Peer ranges on the next Version Packages PR. @data-client/img and @data-client/test peer-depend on @data-client/react with a long hand-kept range (^0.1.0 || … || ^0.18.0). When react goes to 0.19.0 that range is out of range, and apply-release-plan collapses it to plain ^0.19.0. v2 does the same thing today: Version Packages #4020 rewrites both to ^1.0.0. So this PR doesn't cause it, but if you want to keep supporting older react lines, hand-edit those two ranges before merging the regenerated Version Packages PR.
• Small stale comment: the JSDoc in scripts/create-github-releases.mjs still says it's gated by hasChangesets == 'false'. It should say has-changesets now.
• FYI: on every publish run, action v2 will log a warning that it can't read CHANGESETS_OUTPUT, because our publish script is yarn workspaces … npm publish, not changeset publish. That's harmless. It just means the action creates no tags or releases, which create-github-releases: false and the existing comment already expect.

What I actually validated, and how:

• I read action.yml at changesets/action@v2.1.2. Every input name used here exists (version-script, publish-script, commit-message, pr-title, create-github-releases), and so does the has-changesets output. I also read src/run.ts's runPublish. With a custom script and no output file it only warns, so it pushes no tags and makes no releases.
• I ran validateConfig from @changesets/config@4.0.1 against the head .changeset/config.json on Node 24, with a fake workspace made of the linked package names. It returned no errors or warnings. privatePackages normalized to {version: true, tag: false}, and the ___experimentalUnsafeOptions… block is still accepted.
• I loaded the head .changeset/changelog-github-custom.js against @changesets/changelog-github@1.0.1 (ESM-only now) on Node 24, the same way the CLI imports it. require() of the ESM package works, and both getReleaseLine and getDependencyReleaseLine come back as functions. CI uses Node 26, which is inside v3's engines range (^22.11 || ^24 || >=26).
• I read determine-dependents in @changesets/assemble-release-plan@7.0.0. An out-of-range peer dependent gets a patch bump, which matches the description's 1.0.0 to 0.19.0 claim. I also read Version Packages #4020's diff for the current v2 behavior.
• cut.sh: I checked the 0.18.x branch and the @data-client/react@0.18.2 tag. Both still use action v1 with publish: bash scripts/maintenance/publish.sh, so the existing maintenance line isn't touched. Future cuts come from tags released after this PR, which will have publish-script:. Cutting from an older tag fails loudly at the grep -qF publish.sh guard rather than silently.
• gh search code turned up no other hasChangesets or createGithubReleases references beyond the comment above.

Not validated: I didn't run changeset version with either CLI, so I'm taking the "output otherwise identical" comparison from the description. I haven't seen a real Release or beta-release run on v2 + CLI v3; the first push to master after merge is the real test. Bugbot and CircleCI were still pending when I looked.

[ntucker]

Staff engineer (Cursor agent): Re-reviewed at 8f496f0, now that this PR does the CLI v3 migration instead of the v1 revert. LGTM. It does what my earlier follow-up asked for, in this PR: all five inputs are renamed in both workflows, the output is now has-changesets, and the CLI, changelog-github and .changeset/config.json move together. My earlier comments were about the revert, so they no longer describe this diff.

The 1.0.0 to 0.19.0 change in the release plan looks right to me. CLI v3 bumps out-of-range peer dependents by patch instead of major, and with linked that keeps everything at 0.19.0. The current 0.x peer ranges suggest that's the normal release path. Nothing else to change here.

What I actually validated:

• I unpacked @changesets/config@4.0.1. It still reads ___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH.onlyUpdatePeerDependentsWhenOutOfRange and snapshot.useCalculatedVersion/prereleaseTemplate, and privatePackages now defaults to false. So the explicit { version: true, tag: false } is needed to keep v2's behaviour.
• I unpacked @changesets/assemble-release-plan@7.0.0. determineDependents gives an out-of-range peerDependencies dependent a patch bump, which matches the 0.19.0 claim. I didn't run changeset version myself.
• @changesets/changelog-github@1.0.1 is ESM-only. I ran .changeset/changelog-github-custom.js from the head SHA through the same import() plus double-default unwrap that @changesets/apply-release-plan@8.1.1 uses. getReleaseLine and getDependencyReleaseLine both resolve as functions. That was on Node 20.19 on my box, not the Node 26 that Release uses.
• CLI v3's engines (node ^22.11 || ^24 || >=26, yarn >=4.5.2) fit release.yml's Node 26, the repo's yarn@4.18.1, and the root engines.
• Code search on master finds hasChangesets/createGithubReleases only in the two workflows and create-github-releases.mjs, and all of them are updated here. scripts/maintenance/publish.sh doesn't call the CLI, so the dual-spelling cut.sh sed is enough for cuts from older tags.
• gh pr checks: Bugbot and the maintenance scripts job pass. unit_tests-latest was still pending when I looked.

Not validated: Release and beta-release only run on push, so nothing in PR CI exercises the action v2 + CLI v3 path. The first Release run on master after merge is the real test, and it should update #4020 to 0.19.0.

[ntucker]

Folded into master at the request of the maintainer: this change is now part of the changesets/action v2 commit (3879bdb), and master was rewritten from there (new head c9667e5). Closing as superseded.

---

Generated by Claude Code