Release with the shared toolchain instead of a local copy

.changeset/README.md

@@ -6,7 +6,7 @@ Whenever you change something worth mentioning in a release, run `npx changeset`
 and answer the two prompts (which packages, and whether it's a patch/minor/major).
 That writes a small markdown file here, which you commit along with your changes.
 
-At release time `npm run publish` consumes every pending file: it computes the
+At release time `npm run release` consumes every pending file: it computes the
 resulting versions, updates the `package.json`s and the `CHANGELOG.md`s, and
 deletes the files.
 
@@ -38,7 +38,7 @@ README point at that tag.
 
 ## Prereleases
 
-`npm run publish-next` publishes under the `next` dist-tag, leaving `latest`
+`npm run release:next` publishes under the `next` dist-tag, leaving `latest`
 untouched. It works in two modes:
 
 - **as-is** — the pending changesets produce a normal version (say `4.1.0`)
@@ -51,5 +51,5 @@ untouched. It works in two modes:
 Either way the GitHub release is marked as a prerelease, so it never becomes
 the repository's "Latest release".
 
-`npm run publish` refuses to run while `.changeset/pre.json` exists, so a
+`npm run release` refuses to run while `.changeset/pre.json` exists, so a
 forgotten pre mode can't quietly turn a real release into a prerelease.

CLAUDE.md

@@ -50,14 +50,16 @@ npm run test       # Run every package's tests via Turborepo
 
 # Releasing
 npx changeset        # Describe a change, in the PR that makes it
-npm run publish      # Build, test, version, publish, tag, release notes
-npm run publish-next # The same, under the `next` dist-tag
+npm run release      # Build, test, version, publish, tag, release notes
+npm run release:next # The same, under the `next` dist-tag
 ```
 
 Changes worth mentioning in a release need a changeset committed alongside them
 (`npx changeset`); see `.changeset/README.md`. Note that `changeset version`
 runs no npm lifecycle hooks, so anything that used to hang off one — the
-`oclif readme` regeneration, in particular — lives in `toolchain/publish.mjs`.
+`oclif readme` regeneration, in particular — lives in `toolchain/release.mjs`,
+which is this repo's `beforeCommit` hook into the shared
+[`@datocms/release-toolchain`](https://github.com/datocms/release-toolchain).
 
 ### Individual Package Commands
 
@@ -78,7 +80,7 @@ npm run prepack  # Build + generate oclif manifest
 - The WordPress and Contentful import suites talk to live APIs and create real
   DatoCMS projects, which they delete afterwards. They need a `.env` at the root
   (see `.env.sample`) and, for WordPress, `docker compose up` in its package.
-  `npm test` runs them, and so does `npm run publish` — a release cannot be cut
+  `npm test` runs them, and so does `npm run release` — a release cannot be cut
   without that setup. Each prerequisite is checked in a `before` hook that says
   what is missing and how to fix it, so a misconfiguration fails as itself
   rather than as a 401 halfway through an import

README.md

@@ -62,21 +62,27 @@ already had.
    patch/minor/major, then writes a small markdown file under `.changeset/`
    which you commit. `patch` is for bug fixes only; new API surface is
    `minor`. See [`.changeset/README.md`](.changeset/README.md).
-2. **Release.** From an up-to-date, clean `main`, run `npm run publish`.
+2. **Release.** From an up-to-date, clean `main`, run `npm run release`.
    It builds and tests first, then applies the pending changesets (bumping the
    versions and writing the `CHANGELOG.md`s), regenerates the oclif command
    reference in the READMEs of the packages that moved, publishes to npm, and
    only then tags each of them `name@X.Y.Z`, pushes, and publishes one GitHub
    release per tag — its notes are the changelog entries changesets just wrote.
 
-If a release is interrupted, **do not undo anything**: run `npm run publish`
+If a release is interrupted, **do not undo anything**: run `npm run release`
 again. It detects that some package is still missing from the registry and
 resumes the publish instead of starting a new release.
 
-`npm run publish-next` does the same under the `next` dist-tag, leaving
+`npm run release:next` does the same under the `next` dist-tag, leaving
 `latest` untouched; its GitHub releases are marked as prereleases, so they
 don't become the repository's "Latest release" either.
 
+The script is [`@datocms/release-toolchain`](https://github.com/datocms/release-toolchain),
+shared with every other DatoCMS repository and pinned here by tag;
+`toolchain/release.mjs` is the twenty lines that are only true here, where the
+oclif command reference has to be regenerated between the version bump and the
+release commit.
+
 Releases up to v4.0.29 carried a single `vX.Y.Z` tag covering the whole repo.
 Those tags stay where they are; new ones are per package, which is also what the
 source links in the generated command reference now point at.

package.json

@@ -11,14 +11,14 @@
     "build": "turbo run build",
     "test": "turbo run test",
     "changeset": "changeset",
-    "publish": "node toolchain/publish.mjs",
-    "publish-next": "node toolchain/publish.mjs --tag next"
+    "release": "node toolchain/release.mjs",
+    "release:next": "node toolchain/release.mjs --tag next"
   },
   "devDependencies": {
     "@biomejs/biome": "1.6.4",
     "@changesets/cli": "^3.0.1",
     "@datocms/dashboard-client": "^6.1.0",
-    "@manypkg/get-packages": "^3.1.0",
+    "@datocms/release-toolchain": "github:datocms/release-toolchain#v1.2.0",
     "@oclif/test": "^4",
     "@types/chai": "^4",
     "@types/mocha": "^10",