Release with the shared toolchain instead of a local copy - #52
Merged
Conversation
added 2 commits
August 31, 2026 11:55
toolchain/publish.mjs here was the most evolved of four 88-97% identical copies of the same script - the only one with the resume fix - and @datocms/release-toolchain is a port of exactly this file, so the code that releases this repo is the code that has been releasing it. What is left behind is toolchain/release.mjs: the oclif README regeneration, which has to happen between the version bump and the release commit, passed as the shared script's one hook. The scripts are renamed publish -> release, publish-next -> release:next, because 'publish' is a name npm runs itself during 'npm publish'. Claude-Session: https://claude.ai/code/session_01XaYAhzmiJwysZeq1XC5xrQ
Rehearsing the resume against a real registry and a real GitHub repo turned up a bug that every copy of the old script had: killed between 'changeset publish' and 'git push', the next run reads an empty plan - the packages are on the registry and their tags are local, which is all changesets looks at - and aborts with 'there is nothing to release', leaving the commit unpushed and no GitHub release. v1.1.0 finishes that release. Claude-Session: https://claude.ai/code/session_01XaYAhzmiJwysZeq1XC5xrQ
datocms
@datocms/cli
@datocms/cli-plugin-contentful
@datocms/cli-plugin-wordpress
@datocms/cli-utils
commit: |
v1.2.0 adds a guard a package runs from prepublishOnly to refuse a hand-typed 'npm publish'. This repo does not use it: the root package.json is private, so the same slip publishes nothing. The seven single-package repos carry it, where 'npm publish' at the repo root does reach npm. The lockfile is the substantive part of this commit. Changing the spec alone left the previous SHA resolved, so 'npm ci' kept installing v1.0.0 while package.json claimed otherwise. Claude-Session: https://claude.ai/code/session_01XaYAhzmiJwysZeq1XC5xrQ
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
toolchain/publish.mjshere was the most evolved of four 88–97% identical copiesof the same ~280-line script — the only one that ever got the fix letting an
interrupted release resume (
f145fea), which is why@datocms/release-toolchainis aport of this file. The code that releases this repo after the merge is the code
that has been releasing it.
The toolchain is shared by all eleven DatoCMS repos that publish to npm, and is
installed from its repository by git tag rather than published: the
@datocmsscope on npm is what customers install, and internal automation does not belong
there. It also means fixing a release bug is a commit and a tag, not a release —
no bootstrap paradox.
What changed
toolchain/publish.mjs(–280 lines) →toolchain/release.mjs(+30), which isthe oclif README regeneration and nothing else, passed as the shared script's
one hook:
beforeCommit, afterchangeset versionand the lockfile refresh,after the publish plan is read, before
git add -A && git commit. Same placein the order it ran before, comments included.
publish→release,publish-next→release:next. Harmless in this repo,where the root
package.jsonis private, butpublishis a name npm runsitself during
npm publish; the single-package repos migrating next wouldre-enter their own release script if they kept it.
@manypkg/get-packagesdropped — the deleted script was its only consumer.README.md,CLAUDE.mdand.changeset/README.md.The one behaviour change
A release that moves several packages to different versions now gets
release: 4 packagesas its subject and thename@versionlist in the commitbody, instead of all of them spelled into the subject — where a release
touching everything ran to 442 characters. One package alone is still named
(
release: datocms@4.2.1); everything on one version is stillrelease: v4.2.1, which is the usual outcome in a linked group.Two things the shared script adds
vX.Y.Zwhen the repo is one package,name@versionin aworkspace) rather than hard-coded, and a step between
changeset publishandgit pushchecks that its derivation and changesets' agree — while the onlything that has happened is a publish.
visible in the release log.
https://claude.ai/code/session_01XaYAhzmiJwysZeq1XC5xrQ