changesets/action

The changesets/action repository provides a collection of GitHub Actions designed to automate the Changesets workflow. These actions allow you to manage versioning, publishing, and pull request automation for monorepos or individual packages.

Available specialized actions include:

• changesets/action/select-mode: Select the mode to run a Changesets workflow.
• changesets/action/version: Version packages and create or update a pull request.
• changesets/action/pack: Pack publishable packages into tarballs.
• changesets/action/publish: Publish packages to npm.
• changesets/action/pr-status: Generate changeset status in PRs.
• changesets/action/pr-comment: Create or update comments on PRs.

To prevent duplicate comments, you can use the update-id input. When an update-id is provided, the action searches the Pull Request comments for a marker formatted as <!-- changesets-action-pr-comment:update-id --> (or <!-- changesets-action-pr-comment --> if the ID is exactly changesets-action-pr-comment).

If a matching comment is found, the action updates that specific comment with the new body. If no matching comment is found, it creates a new one. This is useful for continuous updates (like CI status or coverage reports) where you want a single, evolving comment rather than a new one for every run.

This action requires Changesets CLI v3. It is not compatible with Changesets CLI v2. If your project uses @changesets/cli version 2, you should use the Changesets action v1 instead.

The validation checks both the version declared in your package.json (dependencies or devDependencies) and the actual installed version of @changesets/cli in your workspace.

The action follows a specific hierarchy to determine the mode:

1. Check for pending changesets: It first reads the current changeset state. If there are changesets present that contain releases, it returns mode: "version". If changesets exist but contain no releases, it returns mode: "none".
2. Check for a publish plan: If no pending changesets are found, it executes the Changesets CLI with the publish-plan command.
   • If the resulting publish plan is empty, it returns mode: "none".
   • If the publish plan contains packages, it returns mode: "publish" and uploads the plan as a GitHub Action artifact.

This logic ensures that you don't attempt to publish when there are still unversioned changesets, and you don't run versioning steps when everything is already up to date.

The Changesets GitHub Action automatically comments on Pull Requests to indicate whether the changes will trigger a version bump. It uses two primary message types based on the presence of changesets in the PR:

🦋 Changeset detected

This message appears when changesets are found. It informs the reviewer that the changes in the PR will be included in the next version bump and provides a summary of the affected packages and their semver types (Major, Minor, or Patch).

⚠️ No Changeset found

This message appears when no changesets are detected. It warns that merging this PR will not cause a version bump for any packages. If the changes should result in a version bump, the developer is prompted to add a changeset.

Both messages include a summary of the release plan (hidden within a <details> HTML element) and a link for maintainers to quickly add a new changeset to the PR.

The pr-comment action is designed to post or update a comment on a Pull Request. It can either create a brand new comment or update an existing one if an update-id is provided.

Required Inputs

• github-token: A GitHub token with permissions to write comments on the Pull Request.
• body: The content of the comment to be posted or updated.

Optional Inputs

• update-id: A unique identifier used to find and update an existing comment. If this is provided, the action will look for a comment containing a specific HTML marker (e.g., <!-- changesets-action-pr-comment:YOUR_ID -->). If found, the existing comment is updated; otherwise, a new comment is created.

Outputs

• comment-id: The ID of the comment that was either created or updated.

The rolldown.config.js file defines the bundling configuration for the project using defineConfig. It specifies multiple entry points for different functional modules (like index, pack, version, etc.), sets the output directory to dist, uses the esm module format, and enables minification and directory cleaning.

import { defineConfig } from "rolldown";

export default defineConfig({
  input: {
    index: "src/index.ts",
    pack: "src/pack/index.ts",
    "pr-status": "src/pr-status/index.ts",
    "pr-comment": "src/pr-comment/index.ts",
    "select-mode": "src/select-mode/index.ts",
    version: "src/version/index.ts",
    publish: "src/publish/index.ts",
  },
  output: {
    dir: "dist",
    format: "esm",
    cleanDir: true,
    minify: true,
    comments: false,
  },
  platform: "node",
});

When instantiating the GitHub class, you can specify the commitMode to determine how Git operations are performed.

new GitHub({
  githubToken: '...',
  cwd: '...',
  commitMode: 'github-api'
});