ci: move to changesets 3, changesets/action v2, checkout v7 and mise-action v4

[rqbazan]

Summary

Moves the release stack to Changesets 3 and bumps the two actions that still ran on old majors. Job ids, job names and workflow names stay the same, so the required checks (Check, Audit workflows) do not move.

 package.json (devDependencies)
-  @changesets/cli               ^2.31.0
-  @changesets/changelog-github  ^0.7.0
+  @changesets/cli               ^3.0.3
+  @changesets/changelog-github  ^1.0.1

 .changeset/config.json
-  $schema  @changesets/config@3.1.1
+  $schema  @changesets/config@4.0.1
+  format   false

 release.yml > Release > "Release or version PR"
-  changesets/action v1.9.0
-    commit, title, publish, setupGitUser: false, commitMode: github-api
-    env.GITHUB_TOKEN = app token
+  changesets/action v2.1.2
+    commit-message, pr-title, publish-script   (same values)
+    github-token = app token                   (unchanged)

 ci.yml, release.yml, workflow-audit.yml
-  actions/checkout v4.4.0
+  actions/checkout v7.0.1
 ci.yml, release.yml
-  jdx/mise-action v2.4.4 (Node 20)
+  jdx/mise-action v4.3.0 (Node 24)   install: true, cache: true kept

Every third-party action stays pinned by full commit SHA with a matching # vX.Y.Z comment. The Mint vland-bot token and Configure git user steps are unchanged. This PR adds no changeset: it changes CI only and ships nothing in the package.

What changes in the next release

On the next push to main, the Release job runs changesets/action v2.1.2 with @changesets/cli 3.0.3. The action checks that the CLI is v3 and passes GITHUB_TOKEN from the github-token input (the vland-bot app token) to the version and publish commands.

The "chore: update versions" PR

• The action runs changeset version on changeset-release/main, which consumes ui-icon-rules.md and type-family-key.md.
• It force-pushes the result through the GitHub API as vland-bot, so the commit is signed. This is the same push mode as the old commitMode: github-api: push-with-git-cli keeps its default, false.
• It updates the open PR chore: update versions #10 in place, with the same title and commit message: chore: update versions.
• Because the config has commit: true, the CLI first makes a local RELEASING commit, and the action squashes it into the single API commit. That is why the unchanged Configure git user step is still needed.
• CLI 3 edits package.json fields in place instead of reformatting the whole file.
• CHANGELOG.md is written exactly as @changesets/changelog-github 1.0.1 generates it, because format is false. The v2 CLI ran its bundled prettier 2.8.8 on it. In the simulation this made no visible difference to this CHANGELOG. The point of format: false is to stop v3's auto mode from picking a formatter on its own.
• Based on the simulation, the PR will look the same as PR chore: update versions #10 does today: version 0.3.0 -> 0.3.1 and a ## 0.3.1 / ### Patch Changes entry with the docs: say that a step's family in tokens.json names a font token #11 and docs: keep the rules for a UI icon and leave the icons to the site #9 bullets.

When that PR is merged

• pnpm changeset publish runs pnpm publish --json --access public --tag latest --no-git-checks for the package. That is the same command as CLI 2.x, checked in the source of both versions.
• Publishing still goes through npm trusted publishing over OIDC. v3 only strips the OTP env vars, so the OIDC id-token env still reaches npm.
• The git tag v0.3.1 and the GitHub release now come from the CHANGESETS_OUTPUT ndjson file. The action sets that file's path, the CLI writes it during pnpm changeset publish, and the action reads it to create the tag and release through the API.

If PR #10 is merged before this branch

0.3.1 ships on the old stack instead. The first v3 Release run then finds no changesets, runs the publish script and exits cleanly with nothing to publish or tag, as changeset publish-plan showed locally.

Both workflows

• They run actions/checkout v7.0.1. This changes nothing here: there are no pull_request_target or workflow_run triggers, and persist-credentials is already false.
• They run jdx/mise-action v4.3.0 on the Node 24 action runtime. The node and pnpm versions still come from mise.toml / mise.lock. mise-action now runs mise install --locked (mise.lock has linux-x64 entries) and exports the mise.toml [env] to the job, which only puts node_modules/.bin on PATH.

The real test is the next "chore: update versions" PR, and only the user merges that one.

Evidence

Local checks on this branch:

pnpm install --frozen-lockfile   Already up to date
pnpm check                       exit 0
actionlint                       exit 0
zizmor 1.30.1                    No findings to report (1 suppressed)   same as origin/main
pnpm changeset status            Packages to be bumped: patch @variablelab/brand   exit 0
pnpm changeset publish-plan      No projects to publish or tag.   exit 0

Release simulation in a throwaway worktree. A test patch changeset was committed first, as CI would have it:

• Before (v2 stack, PR chore: update versions #10 today): 0.3.0 -> 0.3.1, a ## 0.3.1 entry with the docs: say that a step's family in tokens.json names a font token #11 and docs: keep the rules for a UI icon and leave the icons to the site #9 bullets, links and "Thanks @rqbazan".
• After (v3 stack): GITHUB_TOKEN=... pnpm changeset version exited 0 and made RELEASING: Releasing 1 package(s) @variablelab/brand@0.3.1 [skip ci]. It deleted 3 changesets, added the CHANGELOG entry and changed only the version line in package.json. Apart from the test bullet, the CHANGELOG matched PR chore: update versions #10. publish-plan then listed @variablelab/brand@0.3.1 (latest) as the only package to publish.

Nothing was published or pushed from the simulation.

Merge Danger

Door: two-way

Reverting this PR puts back changesets 2, changesets/action v1.9.0, checkout v4 and mise-action v2. The one step that cannot be undone is an npm publish, and that only happens when the user merges the next "chore: update versions" PR. It is the same version (0.3.1) that the old stack would publish.

Blast Radius: release

If the new action or CLI misbehaves, the risk is a broken or wrong "chore: update versions" PR, or a publish that fails to create the tag or release. Package consumers are not affected until a release is merged. CI (Check, Audit workflows) runs on the same job names, so the rulesets keep matching.

🤖 Generated with Claude Code

https://claude.ai/code/session_01BR6x3TNrgMhtDABYaH6hx8

[changeset-bot]

⚠️ No Changeset found

Latest commit: 9f1382c

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