Publicaciones

Los dos paquetes

astro-ignite se publica como dos paquetes de npm que siempre se publican juntos, con la misma versión:

Ambas invocaciones acaban en el mismo código:

npm create astro-ignite@latest mi-sitio     # shim → ejecuta la línea de abajo
npx astro-ignite@latest bootstrap mi-sitio  # directo

La separación en dos paquetes existe porque la convención create-* es la instalación que la gente descubre (todos los scaffolders de Astro/Vite/Next la usan), pero un único binario con subcomandos es más limpio cuando añadamos astro-ignite add <componente> y astro-ignite upgrade. Publicar ambos da a los usuarios las dos UX.

Publicaciones

Mantenidas con Changesets, publicadas mediante .github/workflows/release.yml.

Cómo corre una release

escribe cambios  →  pnpm changeset  →  commit + push  →  PR + merge a main
                                                             │
                                                             │  (cuando un mantenedor esté listo)
                                                             ▼
                                     Actions → Release → Run workflow
                                                             │
                                                             ▼
                          1. aplica los changesets pendientes (sube
                             versiones, escribe el CHANGELOG, refresca
                             pnpm-lock.yaml)
                          2. commitea el cambio de versión localmente
                          3. construye ambos paquetes
                          4. `pnpm changeset publish` — publica en npm vía
                             OIDC trusted publishing (sin NPM_TOKEN)
                          5. solo tras una publicación exitosa, empuja el
                             commit del bump y sus tags

Detalle de implementación: el paso 1 llama a .github/changeset-version.js (un envoltorio fino) que ejecuta changeset version y luego pnpm install --lockfile-only. El commit del cambio de versión se crea antes de publicar (para que el tag publicado apunte a él) pero se empuja solo después de una publicación exitosa — si la publicación falla, no se empuja nada, así que una re-ejecución parte de un estado limpio en vez de uno huérfano (“versión subida pero no publicada”). Una entrada dry_run ejecuta los pasos 1–3 y se detiene antes de publicar, commitear o empujar, como comprobación rápida.

Escribir un changeset

Para cada cambio que tenga que llegar a los usuarios:

pnpm changeset

Prompt interactivo: elige el tipo de bump (patch | minor | major) y escribe un resumen de una línea. Un archivo markdown aparece en .changeset/. Commitealo junto con tu cambio de código.

Regla de bump:

• patch — fix de bug, fix de docs, refactor interno sin cambio de comportamiento.
• minor — nueva feature, nueva plantilla, nuevo prompt, nuevo flag.
• major — cambio de ruptura en flags del CLI, layout del proyecto generado o contrato de las plantillas.

Los paquetes astro-ignite y create-astro-ignite están vinculados en .changeset/config.json — subir uno siempre sube el otro a la misma versión. El shim está acoplado al binario del CLI al que delega.

Archivos involucrados

Setup requerido

Solo una vez por repositorio. Ya hecho para astro-ignite; aquí queda para forks.

• Trusted Publisher de npm configurado en cada paquete (astro-ignite, create-astro-ignite) vía npmjs.com → Settings → Trusted Publisher → GitHub Actions, con Organization/user JordiParraCrespo, Repository astro-ignite, Workflow filename release.yml, Environment name Prod. No hace falta un secret NPM_TOKEN de larga duración — el workflow intercambia un token OIDC de GitHub por una credencial de npm de corta duración y añade provenance automáticamente.
• Settings → Actions → General → Workflow permissions → Read and write permissions (para que el commit del bump de versión se pueda empujar).

Resolución de problemas

“GitHub Actions is not permitted to create or approve pull requests” — activa el toggle en Settings → Actions → General → Workflow permissions del repositorio.

La publicación falla con un error de auth/provenance — comprueba que hay un Trusted Publisher configurado para el paquete en npmjs.com con la organización, repositorio, nombre de workflow (release.yml) y environment (Prod) exactos bajo los que corre el workflow; cualquier discrepancia hace fallar el intercambio OIDC.

npm error 403 Forbidden en la primera publicación — el email de tu cuenta de npm no está verificado. Confírmalo desde el enlace que recibiste al registrarte.

No hay nada que publicar — comprueba que .changeset/ contiene archivos .md aparte de README.md. changeset version/changeset publish no hacen nada si no hay changesets pendientes.