Release with changesets and the shared toolchain, not np

[stefanoverna]

This repo released with np, via a two-line SDKs/RELEASE.md that
prescribed a bare np patch — literally always patch, decided on release day.
There is no CHANGELOG.md here at all, across 24 published versions.

Changesets moves the bump level into the PR that makes the change, and writes
the changelog from it. The release script is
@datocms/release-toolchain —
the same one the four DatoCMS monorepos now run, installed from its repository
by git tag and never published to npm.

The tags do not change. In a repo that is one package, changesets tags
vX.Y.Z, which is exactly what np tagged, so git describe and the existing
tag history carry on unbroken. Verified against this branch:

==> Preflight (release-toolchain v1.2.0)
Aborted: you are not on main. Use --tag to publish a prerelease from a branch.

What changed

• .changeset/ added: config.json (baseBranch: main, access: public —
  which is what makes the scoped package publish publicly without a
  publishConfig) and the standard README.md explaining the bump levels.
• @changesets/cli and @datocms/release-toolchain added; np removed — it
  was pinned at five different versions across these seven repos, with zero
  configuration anywhere, so nothing is lost.
• changeset, release and release:next scripts. The release script must not
  be called publish: this repo's root is the published package, so
  changeset publish → npm publish would run a publish script and the
  release would re-enter itself.
• CHANGELOG.md was already in files — it just never existed. Now something
  writes it.
• A Releasing section in the README.

How to try it

The first release should be a prerelease, which is real in every way except the
dist-tag:

npx changeset pre enter next
npm run release:next        # publishes X.Y.Z-next.0 under `next`, tags, GitHub release
npx changeset pre exit

latest is untouched and the GitHub release is marked as a prerelease.

One thing worth knowing

prepublishOnly here runs npm run build && npm run test, and npm fires it
inside npm publish — so the build and the tests run a second time during a
release, after the toolchain has already gated on them. Harmless, and left alone.

https://claude.ai/code/session_01XaYAhzmiJwysZeq1XC5xrQ

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@datocms/content-link@b146e66

commit: b146e66

[stefanoverna]

One more commit: npm publish typed by hand is now refused

Renaming the script to release means npm run publish fails with npm's
Missing script error. Safe, though npm's suggestion is npm unpublish and it
does not mention release.

npm publish without run is the one that reaches the registry. It skips the
tests, the changelog, the tag and the GitHub release, and npm takes it whenever
the working tree carries a version the registry has not seen. Today a clean
checkout carries the version already published, so the registry answers 403.
That is a side effect of how the toolchain bumps versions, not a decision, and
it stops holding the moment somebody bumps by hand.

So prepublishOnly now runs release-toolchain --assert-release, which passes
only while the release script is the one publishing:

$ npm publish --dry-run
> prepublishOnly
> release-toolchain --assert-release

Aborted: this package is published by 'npm run release'.
  A bare `npm publish` skips the tests, the changelog, the tag and the
  GitHub release, so it is refused here.
  To inspect the tarball without publishing, run 'npm pack'.

npm pack runs prepack rather than prepublishOnly, so reading a tarball
still works, and the pkg-pr-new previews are untouched: it shells out to
npm pack --json, not to npm publish.

The four workspace repos do not get this. Their root package.json is private,
so the same slip at the repo root publishes nothing.