ci: publish releases from GitHub Actions via npm trusted publishing

[daniellee-ux]

Why

Releasing required an interactive npm 2FA OTP, so publishing could not be automated. npm trusted publishing (OIDC, GA since July 2025) removes both the OTP and any stored NPM_TOKEN — the workflow exchanges a short-lived GitHub OIDC token for publish rights, and provenance is attested automatically.

What

Pushing a v* tag cut from main runs .github/workflows/release.yml, which:

1. re-runs the CI gates (core/demo typecheck, check:sync) — a publish can't be undone, so it doesn't assume the tag points at a green commit;
2. verifies the tag matches the package versions and that create-opencanva's caret range covers the core version being published;
3. publishes @opencanva/core, waits for it to resolve on the registry, then publishes create-opencanva.

Three helper scripts, each covering a failure this repo has actually hit or is exposed to:

Script	Guards against
check-release-versions.mjs	tag/package version drift; a stale ^0.3.0 wrapper dep stranding npm create opencanva@latest on the old core
publish-if-needed.mjs	a half-finished release — skips versions already on the registry so workflow_dispatch can re-run it
wait-for-registry.mjs	publishing the wrapper before core resolves → ETARGET for anyone scaffolding in that window

Required one-time setup (outside this repo)

npmjs.com needs a Trusted Publisher on both packages — @opencanva/core and create-opencanva — each with: organization/user daniellee-ux, repository open-canva, workflow filename release.yml, environment blank. All fields are case-sensitive and must match exactly.

Requirements met by the workflow: id-token: write permission, Node 22, npm upgraded to latest (trusted publishing needs npm ≥ 11.5.1; Node 22 ships npm 10.x).

Verification

check-release-versions.mjs and wait-for-registry.mjs were run locally: the version guard passes on v0.4.0, fails with a clear message on a mismatched tag, and the registry wait correctly reports @opencanva/core@0.4.0 as not yet published. The publish step itself is exercised by the first real tag.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e4f7ce9cfc

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Require manual releases to target a version tag

When workflow_dispatch is launched with a branch selected, github.ref_type is not tag, so this expression passes an empty string and check-release-versions.mjs deliberately skips tag validation; checkout and both publish steps then operate on that branch's HEAD. The suggested half-finished-release path can therefore publish an untagged version—or the next version after main has advanced—instead of resuming the intended release. Require a tag ref or explicit version-tag input and validate it before publishing.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Run the template release gates before publishing

When a tag points at a commit whose init template is invalid, this sequence proceeds from the demo typecheck directly to check:sync and publishing, even though .github/workflows/ci.yml also runs the template TypeScript check and scripts/check-template-scaffold.mjs isolation check. Those checks catch template dependency and packed-scaffold failures that the core/demo checks cannot, so the workflow's stated defense against releasing an unverified tag still permits publishing a broken opencanva init; include both existing CI steps before the publish steps.

Useful? React with 👍 / 👎.