Skip to content

Publish a preview of every package on every push - #58

Merged
stefanoverna merged 1 commit into
mainfrom
feat/continuous-releases
Aug 31, 2026
Merged

Publish a preview of every package on every push#58
stefanoverna merged 1 commit into
mainfrom
feat/continuous-releases

Conversation

@stefanoverna

Copy link
Copy Markdown
Member

Every commit pushed to a branch here now produces an installable tarball of
every package, without publishing anything to npm:

npm i https://pkg.pr.new/@datocms/cma-client@<commit-sha>

Why

This is the thing a monorepo cannot give us, because our packages are spread
across several of them. Today, trying a client change inside a consumer that
lives in another repository means pinning a git branch by hand — see
datocms/cms#365 — which works, is invisible to review, and nobody remembers to
undo. npm link is the other option, and it breaks in its own ways.

Verified end-to-end on this branch

The run on commit 38b0774 published all 9 packages. Installing one of them in a
throwaway project resolves the siblings from the same commit, not from npm:

node_modules/@datocms/cma-client         https://pkg.pr.new/.../@datocms/cma-client@38b0774
node_modules/@datocms/cma-client-node    https://pkg.pr.new/@datocms/cma-client-node@38b0774
node_modules/@datocms/rest-client-utils  https://pkg.pr.new/.../@datocms/rest-client-utils@38b0774

while datocms-structured-text-utils still comes from npm, correctly — it
lives in another repo. So a change spanning several packages can be tried as
one coherent set.

Choices worth reviewing

Pushes only, no fork pull requests. The workflow runs on pushes to branches
of this repo, which only people with write access can make. A fork PR publishes
nothing. This is deliberate: pkg.pr.new URLs carry our namespace, and the
tarballs are served unauthenticated, so an unreviewed fork should not be able to
mint one. pkg.pr.new documents an "approved pull requests only" recipe if we
ever want fork previews gated behind a maintainer's review — easy follow-up.

A separate workflow, not a step in node.js.yml. That one runs a matrix of
two Node versions and needs the API secrets; pkg-pr-new must run exactly once
per workflow run, and a preview is worth having even when the live-API suite is
red.

No changeset. Nothing about the published packages changes.

One thing to know

Previews are throwaway and the URLs stop resolving after a while. They must
never end up in a package.json that ships — same rule as the git-branch pins
they replace, but at least these are obviously temporary.

A change to a client can now be tried inside a consumer that lives in
another repository — `cms`, a demo, a customer project — by installing a
real tarball built from the branch:

    npm i https://pkg.pr.new/@datocms/cma-client@<commit-sha>

Nothing reaches npm, no version is spent, and there is nothing to clean
up afterwards. This replaces pinning a git branch by hand, which is what
we have been doing (datocms/cms#365) and which nobody remembers to undo.

Runs only on pushes to branches of this repo, so a fork cannot mint a URL
under our namespace without a maintainer pushing the code first.
Claude-Session: https://claude.ai/code/session_01TbxhxyU1XBsSKtoCJXwAoD
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant