chore(deps): bump changesets/action from 1 to 2

[dependabot]

Bumps changesets/action from 1 to 2.

Release notes

Sourced from changesets/action's releases.

v2.0.0

Major Changes

• #692 cb3f011 Thanks @​Andarist! - Release commits and tags are now pushed using the GitHub API by default.

  Replace the commit-mode input with the boolean push-with-git-cli input. Set push-with-git-cli: true to continue using the Git CLI.

  Regardless of the push mode, custom GitHub tokens must be passed explicitly through the github-token input. The GITHUB_TOKEN environment variable and credentials configured by actions/checkout or embedded in remote URLs are not substitutes for this input. When the Git CLI is enabled, github-token takes precedence over those repository credentials.

• #680 ca57073 Thanks @​bluwy! - Add a new push-git-tags option that complements create-github-releases to control specifically if git tags should be created but not GitHub releases.

  If create-github-releases was previously set to false, which also indirectly disabled git tag creation, git tags will now be created instead by default. If this is not desired, set push-git-tags to false explicitly.

• #657 4f718b5 Thanks @​Andarist! - Removed compatibility support for old Changesets v1.

• #681 7359107 Thanks @​bluwy! - Rename the root action inputs and outputs to better match the sub-actions' conventions.

  Inputs:

  • version -> version-script
  • publish -> publish-script
  • commit -> commit-message
  • title -> pr-title
  • branch -> pr-base-branch

  Outputs:

  • pull-request-number -> pr-number

• #674 164652b Thanks @​bluwy! - Remove support for passing custom GitHub token through the GITHUB_TOKEN environment variable. It should be passed to the github-token input instead.

• #659 5649ff4 Thanks @​bluwy! - Remove cwd option for changesets/action. Use the step working-directory option instead to change the directory.

• #673 823cf74 Thanks @​bluwy! - Update to Changesets v3 packages

• #695 469993c Thanks @​bluwy! - Removed .npmrc handling when the NPM_TOKEN environment variable is set.

  Authentication should be handled via Trusted Publishing instead. If a token is still needed, use actions/setup-node to set it up instead via the registry-url option. Check out the updated action README for more information of setting up npm authentication in GitHub Actions.

• #668 0eae789 Thanks @​bluwy! - Rename the input and output names to kebab-case instead of camelCase to match the official GitHub actions pattern

Minor Changes

• #656 a12d90d Thanks @​bluwy! - Add new /select-mode, /version, and /publish sub-actions to better control version and publish steps

• #678 f71ae04 Thanks @​Andarist! - Published packages detection done through stdout parsing was replaced with one based on the shared output file using CHANGESETS_OUTPUT environment variable. When using custom scripts this environment variable should always be passed down to the Changesets CLI invocations.

Patch Changes

• #699 5b307d3 Thanks @​Andarist! - Validate that projects use Changesets CLI v3 and direct Changesets CLI v2 users to changesets/action@v1.

... (truncated)

Changelog

Sourced from changesets/action's changelog.

@​changesets/action

2.1.1

Patch Changes

• #721 da1ea29 Thanks @​KEBABSELLER6! - Fixed typo in renamed inputs from v1 to v2

2.1.0

Minor Changes

• #718 3b7c71c Thanks @​bluwy! - Add a cwd input to the root action, /select-mode, /version, /pack, and /publish sub-actions to set the current working directory to execute Changesets in. This input existed in v1 but was incorrectly removed.

Patch Changes

• #716 6f58ba3 Thanks @​bluwy! - Update pr-status message to link to the new faq page

2.0.0

Major Changes

• #692 cb3f011 Thanks @​Andarist! - Release commits and tags are now pushed using the GitHub API by default.

  Replace the commit-mode input with the boolean push-with-git-cli input. Set push-with-git-cli: true to continue using the Git CLI.

  Regardless of the push mode, custom GitHub tokens must be passed explicitly through the github-token input. The GITHUB_TOKEN environment variable and credentials configured by actions/checkout or embedded in remote URLs are not substitutes for this input. When the Git CLI is enabled, github-token takes precedence over those repository credentials.

• #680 ca57073 Thanks @​bluwy! - Add a new push-git-tags option that complements create-github-releases to control specifically if git tags should be created but not GitHub releases.

  If create-github-releases was previously set to false, which also indirectly disabled git tag creation, git tags will now be created instead by default. If this is not desired, set push-git-tags to false explicitly.

• #657 4f718b5 Thanks @​Andarist! - Removed compatibility support for old Changesets v1.

• #681 7359107 Thanks @​bluwy! - Rename the root action inputs and outputs to better match the sub-actions' conventions.

  Inputs:

  • version -> version-script
  • publish -> publish-script
  • commit -> commit-message
  • title -> pr-title
  • branch -> pr-base-branch

  Outputs:

  • pull-request-number -> pr-number

• #674 164652b Thanks @​bluwy! - Remove support for passing custom GitHub token through the GITHUB_TOKEN environment variable. It should be passed to the github-token input instead.

... (truncated)

Commits

• 8488615 v2.1.1
• d7669c8 Version Packages (#722)
• da1ea29 Fix typo in renamed inputs (#721)
• 7545547 Version Packages (#719)
• 3043070 Prevent test warning annotations (#720)
• 3b7c71c Add back cwd input (#718)
• 6f58ba3 Update pr-status message links to new faq (#716)
• e52ce9e Version Packages (#715)
• 78fdc6b Exit pre mode (#714)
• 187a104 Update deps for stable (#709)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 7948779

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

[ev-vaultkeeper]

Bumping changesets/action v1 → v2 without updating the workflow will break the release pipeline

v2 is a major release with breaking input/output renames, and .github/workflows/push.yml (the only consumer of this action) still uses the v1 names. I compared the v1 and v2 action.yml and three things the workflow relies on have changed:

Used in workflow	v1	v2
input	version:	version-script:
input	setupGitUser:	removed
output	hasChangesets	has-changesets

Why this is high risk

Unknown with: inputs and unknown output references don't fail the step — they're silently ignored / resolve to empty strings — so CI stays green while the release logic quietly misbehaves. Concretely, after this merges the next release run would:

1. version: is ignored → the version step reverts to the default changeset version. The repo's version script is changeset version && pnpm install --no-frozen-lockfile, so the pnpm install lockfile update would no longer run and version PRs would ship an out-of-date pnpm-lock.yaml. In v2 this must be version-script:.

2. steps.changesets.outputs.hasChangesets resolves to empty. This output is now has-changesets. It's consumed at line 123 (job output) and line 157 (if: … == 'false'). With an empty value, the Create Tags step (if: … hasChangesets == 'false') never runs, and consequently the release job gate at line 170 (needs.create-tags.outputs.has-changesets == 'false' && …) is never satisfied — tags are never created and nothing is ever released. These references need to be updated to has-changesets.

3. setupGitUser: false is no longer a recognized input (removed in v2). Harmless dead config, but should be removed. Note the workflow already configures git user in a separate step and checks out with ssh-key: COMMIT_KEY.

Also worth confirming: token & push mode (line 151–153)

v2 removed support for authenticating via the GITHUB_TOKEN environment variable — a custom token must be passed through the github-token input (which defaults to ${{ github.token }}). More importantly, v2 now pushes release commits/tags via the GitHub API by default instead of the git CLI. Today this job checks out with ssh-key: COMMIT_KEY specifically so pushes go through that deploy key (typically to trigger downstream CI on the version PR). Under v2's default, the push would instead use github.token via the API, bypassing COMMIT_KEY. If you want to preserve the current behavior, set push-with-git-cli: true (and note the API push path requires the token to have contents: write / pull-requests: write, which the create-tags job doesn't currently declare).

Why CI didn't catch this

push.yml only triggers on push to master/main, so none of the green PR checks actually run the v2 action — the breakage would only appear on the first post-merge release.

Suggested change

      - name: Create Release Pull Request
        id: changesets
        uses: changesets/action@v2
        with:
          version-script: pnpm run version
          # push-with-git-cli: true   # keep git-CLI/ssh-key push behavior if desired
        env:
          HUSKY: 0

and update the two hasChangesets references (lines 123 and 157) to has-changesets.

The version bump itself is fine — it just needs the workflow updated in the same PR. Since Dependabot won't do that, this needs a manual follow-up commit before merging.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​changesets/​cli@​3.0.1

View full report

[Matt (matt-evervault)]

Review comments addressed in 343a81c — plus a blocker the review missed

changesets/action@v2 refuses to run against Changesets CLI v2 at all, so the workflow renames on their own were not enough. validateChangesetsCliVersion() runs first and throws on major(@changesets/cli) === 2 (source); we were on 2.27.11. This PR therefore bumps the CLI to ^3.0.1 alongside the action.

changesets/action v1 → v2

Change	Note
version: → version-script:	v2 throws on the old name (not silently ignored, as the review said)
hasChangesets → has-changesets	2 refs (job output L123, step if: L157). This one is silent — empty string, no error → no tags, no releases
setupGitUser: false removed	No longer a recognised input; git user is already set in its own step
GITHUB_TOKEN env removed	v2 throws if it's set and differs from github-token, which already defaults to ${{ github.token }}
push-with-git-cli: true added	Keeps release pushes on the COMMIT_KEY deploy key rather than v2's new GitHub-API default

@changesets/cli v2 → v3

Change	Note
changeset tag → changeset git-tag	Renamed in v3; used in the Create Tags step
privatePackages: { version: true, tag: false }	v3 stopped versioning private packages by default. changeset status failed outright: "@evervault/browser depends on the skipped package shared". This restores the exact v2 default
$schema → @changesets/config@4.0.0	Matches the config package CLI 3.0.1 depends on

Already-satisfied v3 requirements, checked: Node ^22.11 \|\| ^24 \|\| >=26 (we're on v24), pnpm >=10 (10.26.1), no prettier key to migrate to format, @changesets/cli/changelog export path unchanged.

Verification

Since push.yml only triggers on push to master, none of the green checks on this PR exercise any of the above — the same reason the original break would have surfaced only post-merge. So I ran the CLI paths locally against this branch:

• changeset status — config validation passes; correctly resolves 7 packages from a scratch changeset
• changeset version — bumps versions and writes CHANGELOGs as expected (reverted)
• changeset git-tag — command exists in v3
• pnpm install --frozen-lockfile — clean; lockfile diff is confined to the @changesets/* subtree (+12 / -150 packages, no shared runtime deps touched)
• pnpm run build and pnpm run typecheck — pass

What is still not covered by any test: the actual push-with-git-cli: true push through COMMIT_KEY, and GitHub release creation. Those only run on the first post-merge release, so worth watching that run.

No changeset file added — this is release tooling only, no publishable package changes.