ci: replace changesets with release-please

.github/dependabot.yml

@@ -7,7 +7,7 @@
 # fit. The intent: peerDependency ranges on shipped packages (e.g. the
 # Next.js peer on @faustwp/core) shouldn't be rewritten automatically as
 # part of a routine dependency bump; those are deliberate compatibility
-# decisions that warrant their own changeset and review.
+# decisions that warrant their own pull request and review.
 
 version: 2
 

.github/workflows/npm-publish.yml

@@ -3,33 +3,20 @@ name: Publish to npm
 on:
   workflow_call:
     inputs:
-      pre-build-command:
-        description: 'Command to run before building (e.g., snapshot versioning)'
-        type: string
-        required: false
-        default: ''
-      publish-command:
-        description: 'Command to run for publishing'
+      paths:
+        description: 'JSON array of package paths released by release-please (e.g. ["packages/faustwp-core"])'
         type: string
         required: true
-      push-tags:
-        description: 'Whether to push git tags after publishing'
-        type: boolean
-        required: false
-        default: false
 
 # No permissions block — inherits from caller workflow.
-# Release caller grants contents: write + id-token: write (enables git push and OIDC).
-# Nightly caller grants contents: read + id-token: write (enables checkout and OIDC).
+# The release caller grants id-token: write, which enables npm OIDC.
 
 jobs:
   publish:
     runs-on: ubuntu-22.04
     steps:
       - name: Checkout Repo
         uses: actions/checkout@v7
-        with:
-          fetch-depth: 0
 
       - name: Setup Node.js 22.x
         uses: actions/setup-node@v7
@@ -54,26 +41,15 @@ jobs:
           fi
           echo "OIDC token endpoint available"
 
-      - name: Pre-build
-        if: inputs.pre-build-command != ''
-        run: ${{ inputs.pre-build-command }}
-
       - name: Build packages
         run: npm run build
 
       - name: Publish to npm
-        run: ${{ inputs.publish-command }}
-
-      - name: Push tags
-        if: inputs.push-tags
-        run: git push origin --tags
-
-      - name: Create GitHub Releases
-        if: inputs.push-tags
         env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          PATHS: ${{ inputs.paths }}
         run: |
-          git tag --points-at HEAD | while IFS= read -r tag; do
-            echo "Creating GitHub release for $tag"
-            gh release create "$tag" --title "$tag" --generate-notes || true
+          # The plugin is released to wordpress.org by release-plugin.yml, not npm.
+          for path in $(jq -r '.[] | select(startswith("packages/"))' <<< "$PATHS"); do
+            echo "Publishing $path"
+            npm publish --workspace "$path"
           done

.github/workflows/release-packages.yml

@@ -6,44 +6,75 @@ on:
       - canary
 
 permissions:
-  contents: write      # For creating releases/tags and pushing tags
-  pull-requests: write # For creating version PRs
+  contents: write      # For creating releases/tags and pushing to the release PR branch
+  pull-requests: write # For creating the release PR
   id-token: write      # For npm OIDC authentication
 
 jobs:
-  changesets:
-    name: Manage Changesets
+  release-please:
+    name: Release Please
     runs-on: ubuntu-22.04
     outputs:
-      has-changesets: ${{ steps.changesets.outputs.hasChangesets }}
+      releases-created: ${{ steps.release.outputs.releases_created }}
+      paths-released: ${{ steps.release.outputs.paths_released }}
+      plugin-release-created: ${{ steps.release.outputs['plugins/faustwp--release_created'] }}
+      plugin-tag: ${{ steps.release.outputs['plugins/faustwp--tag_name'] }}
+      pr: ${{ steps.release.outputs.pr }}
     steps:
-      - name: Checkout Repo
+      - uses: googleapis/release-please-action@45996ed1f6d02564a971a2fa1b5860e934307cf7 # v5.0.0
+        id: release
+        with:
+          target-branch: canary
+
+  # release-please bumps plugins/faustwp/package.json but knows nothing about
+  # the WordPress plugin header, the readme.txt Stable tag, or the readme.txt
+  # changelog. Sync those onto the release PR branch so they ship together.
+  sync-plugin-files:
+    name: Sync plugin version files
+    needs: release-please
+    if: needs.release-please.outputs.pr
+    runs-on: ubuntu-22.04
+    steps:
+      - name: Checkout release PR branch
         uses: actions/checkout@v7
         with:
-          # This makes Actions fetch all Git history so that Changesets can generate changelogs with the correct commits
-          fetch-depth: 0
+          ref: ${{ fromJSON(needs.release-please.outputs.pr).headBranchName }}
 
       - name: Setup Node.js 22.x
         uses: actions/setup-node@v7
         with:
           node-version: 22.x
 
-      - name: Install Dependencies
-        run: npm ci
+      - name: Update plugin header, Stable tag, and readme.txt changelog
+        run: node scripts/versionPlugin.js
 
-      - name: Create Release Pull Request
-        id: changesets
-        uses: changesets/action@v1
-        with:
-          version: npm run version
-        env:
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+      - name: Commit changes
+        run: |
+          if git diff --quiet; then
+            echo "Plugin files already in sync"
+            exit 0
+          fi
+          git config user.name "github-actions[bot]"
+          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
+          git commit -am "chore: sync plugin version files"
+          git push
 
   publish:
     name: Publish to npm
-    needs: changesets
-    if: needs.changesets.outputs.has-changesets == 'false'
+    needs: release-please
+    if: needs.release-please.outputs.releases-created == 'true'
     uses: ./.github/workflows/npm-publish.yml
     with:
-      publish-command: npx changeset publish
-      push-tags: true
+      paths: ${{ needs.release-please.outputs.paths-released }}
+
+  # Tags created with GITHUB_TOKEN don't trigger other workflows, so the
+  # plugin tag push alone won't start the wordpress.org deploy. Call it here.
+  release-plugin:
+    name: Deploy plugin
+    needs: release-please
+    if: needs.release-please.outputs.plugin-release-created == 'true'
+    uses: ./.github/workflows/release-plugin.yml
+    with:
+      tag: ${{ needs.release-please.outputs.plugin-tag }}
+      dry_run: false
+    secrets: inherit

.github/workflows/release-plugin.yml

@@ -4,6 +4,22 @@ on:
   push:
     tags:
       - '@faustwp/wordpress-plugin@*'
+  workflow_call:
+    inputs:
+      tag:
+        description: 'Tag to operate on (e.g. @faustwp/wordpress-plugin@1.8.8)'
+        required: true
+        type: string
+      dry_run:
+        description: 'Build artifacts but skip the wordpress.org deploy job'
+        required: false
+        default: false
+        type: boolean
+      redeploy:
+        description: 'Delete the existing SVN tag before publishing'
+        required: false
+        default: false
+        type: boolean
   workflow_dispatch:
     inputs:
       tag:

.release-please-manifest.json

@@ -0,0 +1,7 @@
+{
+  "packages/faustwp-core": "3.4.1",
+  "packages/faustwp-cli": "3.4.1",
+  "packages/blocks": "6.1.9",
+  "packages/block-editor-utils": "0.3.8",
+  "plugins/faustwp": "1.8.12"
+}

CONTRIBUTING.md

@@ -39,7 +39,7 @@ In general, things we find useful when reviewing suggestions are:
 0. [A bug or feature you want to work on](https://github.com/wpengine/faustjs/labels/help%20wanted)! If you have found a new bug or want to propose a feature, please [create an issue](https://github.com/wpengine/faustjs/issues/new/choose) before starting a pull request.
 1. [A GitHub account](https://github.com/join).
 2. A working copy of the code. See [DEVELOPMENT.md](/DEVELOPMENT.md).
-3. A `changeset` that describes the changes you're making. You can create a `changeset` by running `npm run changeset` from the monorepo root.
+3. A pull request title that follows [Conventional Commits](https://www.conventionalcommits.org/), such as `fix(core): handle expired tokens`. We use it to version packages and write changelogs. See [DEVELOPMENT.md](/DEVELOPMENT.md#how-commits-map-to-releases).
 
 ## Housekeeping
 

DEVELOPMENT.md

@@ -162,41 +162,43 @@ We use the [feature branch workflow](https://www.atlassian.com/git/tutorials/com
 
 - Create a new branch for the feature
 - Make changes to the code
-- Use `npm run changeset` to create a changeset describing any package or plugin updates
 - Commit your changes
-- Open a pull request to the `canary` branch
+- Open a pull request to the `canary` branch with a [Conventional Commits](https://www.conventionalcommits.org/) title, scoped to the package you changed (e.g. `fix(core): ...`, `feat(faustwp): ...`)
 - Squash and Merge the pull request into the `canary` branch
 
-**Note**: We use Squash and Merge when merging pull requests into the `canary` branch.
+**Note**: We use Squash and Merge when merging pull requests into the `canary` branch, so the pull request title becomes the commit message that drives versioning and changelogs.
 
 ## Deployment
 
-Developers with full GitHub repository access can create public releases. We use [Changesets](https://github.com/atlassian/changesets) to automate the versioning and deployment process for all of our packages and plugins.
+Developers with full GitHub repository access can create public releases. We use [release-please](https://github.com/googleapis/release-please) to automate versioning and deployment for all of our packages and the plugin. Configuration lives in `release-please-config.json` and `.release-please-manifest.json`.
 
-### Adding a changeset
+### How commits map to releases
 
-To add a new changeset for a new feature, bugfix or other change please see the [changeset documentation](https://github.com/changesets/changesets/blob/main/docs/adding-a-changeset.md).
+release-please reads the commits merged to `canary` since the last release of each package. Only commits that touch a package's directory count toward that package.
+
+- `fix:` releases a patch version.
+- `feat:` releases a minor version.
+- `!` after the type (e.g. `feat!:`) or a `BREAKING CHANGE:` footer releases a major version.
+- `deps:` releases a patch version and lists the change under Dependencies.
+- `chore:`, `docs:`, `ci:`, `test:`, `refactor:`, `build:`, and `style:` don't trigger a release.
+
+`@faustwp/core` and `@faustwp/cli` always share a version number.
 
 ### Versioning
 
-When you are ready to release, you should first create the new package and plugin versions.
+release-please keeps a release PR open against `canary` and updates it as commits land.
 
-1. Go to [pull requests](https://github.com/wpengine/faustjs/pulls), and view the "Version Packages" PR.
+1. Go to [pull requests](https://github.com/wpengine/faustjs/pulls), and view the release-please PR.
 2. Review the PR:
    - [ ] Changelog entries were created in all updated packages or plugins.
    - [ ] Version numbers were appropriately bumped in the relevant package.json files.
-   - [ ] All `.changeset/*.md` files were removed.
    - [ ] Version number updated in the main plugin file and readme.txt (Plugin versioning only)
    - [ ] The plugin's readme.txt changelog has been updated with the latest 3 versions (Plugin versioning only)
-3. Approve, then "Squash and merge" the "Version Packages" PR into `canary`.
-
-### Publishing the @faustwp packages
-
-The @faustwp packages are automatically published to NPM through a GitHub action once the "Version Packages" PR is merged.
+3. Approve, then "Squash and merge" the release PR into `canary`.
 
-### Publishing the FaustWP plugin
+### Publishing
 
-Once the "Version Packages" PR is merged, create a new release on GitHub with a tag of `plugin/faustwp/v[version]`. This will kick off our GitHub Action to deploy the `faustwp` plugin to WordPress.org.
+Merging the release PR tags each released package (e.g. `@faustwp/core@3.4.2`), creates a GitHub release for it, and publishes the npm packages. If the plugin was released, the same workflow deploys it to WordPress.org.
 
 Once deployed, the updated packages and plugin will be visible here: