Skip to content

v1.5.1

v1.5.1 #10

Workflow file for this run

name: Release
# A GitHub Release is the publish. Creating one — with a tag like `v1.0.1` —
# runs this, and nothing else does.
#
# What this replaced: changesets' own bot, which opened a "Version Packages"
# pull request on every merge and published when that PR was merged. That is a
# good design for a repository with several maintainers, where the version bump
# wants reviewing before it ships. Here it meant approving a pull request every
# time for a diff nobody was going to argue with — so the versioning moves to a
# local command (`pnpm version-packages`) and the shipping moves to the moment
# you say so.
on:
release:
types: [published]
# Publishing is not something to do twice at once.
concurrency:
group: release
cancel-in-progress: false
permissions:
contents: read
# The publish credential. Each package names this repository and this
# workflow FILENAME as its trusted publisher on npm, so the registry accepts
# this run's short-lived OIDC identity and there is no token to leak or
# rotate. Renaming this file stops publishing until npm is told the new name.
#
# It also carries the provenance attestation tying each tarball to this
# commit and this workflow — the badge on the npm page.
id-token: write
jobs:
publish:
runs-on: ubuntu-latest
steps:
# The release's tag, not the branch: what ships is what was tagged.
- uses: actions/checkout@v7
with:
ref: ${{ github.event.release.tag_name }}
# The pnpm VERSION comes from the root manifest's `packageManager`, not
# from this action's major. Worth knowing before anyone bumps that field:
# OIDC publishing works on pnpm 10 and regressed on 11 (pnpm/pnpm#11513),
# where the token exchange 404s. This job's whole credential is that
# exchange.
- uses: pnpm/action-setup@v6
- uses: actions/setup-node@v7
with:
node-version-file: package.json
cache: pnpm
registry-url: https://registry.npmjs.org
- run: pnpm install --frozen-lockfile
# A tag that disagrees with the manifests would publish a version nobody
# asked for, described by release notes about a different one — and a
# publish cannot be taken back, only superseded. All four packages share
# one version (see `fixed` in .changeset/config.json), so checking the
# one a consumer installs checks all of them.
- name: Check the tag against the manifests
run: |
TAG="${{ github.event.release.tag_name }}"
VERSION="$(node -p "require('./packages/vanilla/package.json').version")"
if [ "$TAG" != "v$VERSION" ]; then
echo "Tag $TAG does not match the packaged version $VERSION."
echo "Run 'pnpm version-packages', commit that, and tag the commit."
exit 1
fi
- run: pnpm exec playwright install --with-deps chromium
# Publishing something that does not pass its own tests is worse than
# not publishing: it cannot be taken back, only superseded.
- run: pnpm lint
- run: pnpm typecheck
- run: pnpm test
- run: pnpm build
# What the tests cannot see: the shape of what actually gets published —
# an `exports` map pointing at a file the tarball does not carry, a
# `.d.ts` that will not resolve under a consumer's moduleResolution.
- run: pnpm check:packages
# `--no-git-checks` because this runs on a detached tag, which pnpm would
# otherwise refuse as "not on a branch". Versions already on the registry
# are skipped rather than failing, so re-running a release is safe.
- name: Publish
env:
NPM_CONFIG_PROVENANCE: true
run: pnpm -r publish --access public --no-git-checks