EN
project

Releases

How astro-ignite is versioned and shipped to npm — the two-package CLI, stable releases, and per-PR betas.

Last updated

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:

terminalbash
npm create astro-ignite@latest my-site     # shim → spawns the line below
npx astro-ignite@latest bootstrap my-site  # direct

The 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:

terminalbash
pnpm changeset

Interactive 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/user JordiParraCrespo, Repository astro-ignite, Workflow filename release.yml, Environment name Prod. No long-lived NPM_TOKEN secret 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.