Releases
How astro-ignite is versioned and shipped to npm — the two-package CLI, stable releases, and per-PR betas.
The two packages
astro-ignite ships as two npm packages that always publish together at the same version:
| Package | What it is |
|---|---|
astro-ignite |
The primary CLI. Subcommand-based: bootstrap today, add / upgrade planned. |
create-astro-ignite |
A thin shim that exists so npm create astro-ignite@latest works. Delegates to astro-ignite bootstrap. |
Both invocations reach the same code:
npm create astro-ignite@latest my-site # shim → spawns the line below
npx astro-ignite@latest bootstrap my-site # directThe two-package split exists because the create-* convention is the discoverable install (every Astro/Vite/Next scaffolder uses it), but a single binary with subcommands is the cleaner UX once we add astro-ignite add <component> and astro-ignite upgrade. Shipping both gives users both UXes.
Releases
| Trigger | npm dist-tag | Version shape |
|---|---|---|
| Manually dispatched from Actions → Release → Run workflow | latest |
semver, e.g. 0.1.0 |
Maintained via Changesets, published through .github/workflows/release.yml.
How a release runs
write changes → pnpm changeset → commit + push → PR + merge to main
│
│ (whenever a maintainer is ready)
▼
Actions → Release → Run workflow
│
▼
1. apply pending changesets (bump versions,
write CHANGELOG, refresh pnpm-lock.yaml)
2. commit the version bump locally
3. build both packages
4. `pnpm changeset publish` — ships to npm via
OIDC trusted publishing (no NPM_TOKEN)
5. only after a successful publish, push the
bump commit and its tags
Implementation detail: step 1 calls .github/changeset-version.js (a thin wrapper) which runs changeset version and then pnpm install --lockfile-only. The version-bump commit is created before publish (so the published tag points at it) but pushed only after a successful publish — a failed publish leaves nothing pushed, so a re-run starts clean instead of from an orphaned “bumped but not published” state. A dry_run input runs steps 1–3 and stops before publishing, committing, or pushing, for a sanity check.
Writing a changeset
For every change that should ship to users:
pnpm changesetInteractive prompt: pick the bump type (patch | minor | major) and write a one-line summary. A markdown file lands in .changeset/. Commit it alongside your code change.
Bump-type rules of thumb:
patch— bug fix, doc fix, internal refactor with no behavior change.minor— new feature, new template, new prompt, new flag.major— breaking change to CLI flags, generated project layout, or template contract.
The astro-ignite and create-astro-ignite packages are linked in .changeset/config.json — bumping one always bumps the other to the same version. The shim is tightly coupled to the CLI binary it delegates to.
Files involved
| Path | Purpose |
|---|---|
.github/workflows/release.yml |
The single manually-dispatched release job (apply changesets, build, publish via OIDC, then push). |
.github/changeset-version.js |
changeset version + lockfile refresh. |
.changeset/config.json |
changesets config (access, ignore list, linked packages). |
.changeset/*.md |
Pending change descriptions, consumed at release time. |
Required setup
This is one-time-per-repo setup. Already done for astro-ignite, listed here for forks.
- npm Trusted Publisher configured on each package (
astro-ignite,create-astro-ignite) via npmjs.com → Settings → Trusted Publisher → GitHub Actions, with Organization/userJordiParraCrespo, Repositoryastro-ignite, Workflow filenamerelease.yml, Environment nameProd. No long-livedNPM_TOKENsecret is needed — the workflow exchanges a GitHub OIDC token for a short-lived npm credential and attaches build provenance automatically. - Settings → Actions → General → Workflow permissions → Read and write permissions (so the version-bump commit can be pushed).
Troubleshooting
“GitHub Actions is not permitted to create or approve pull requests” — flip the toggle in repo Settings → Actions → General → Workflow permissions.
Publish fails with an auth/provenance error — check that a Trusted Publisher is configured for the package on npmjs.com with the exact organization, repository, workflow filename (release.yml), and environment name (Prod) the workflow runs under; a mismatch on any field causes the OIDC exchange to fail.
npm error 403 Forbidden on first publish — your npm account email isn’t verified. Confirm via the email link sent at signup.
Nothing to release — check .changeset/ contains .md files besides README.md. changeset version/changeset publish are no-ops when there are no pending changesets.