Publicar la CLI

El paquete npm sigue llamándose @soymanolo/create-my-saas, aunque el repositorio es LAKBAST/create-my-saas. El workflow .github/workflows/publish.yml se activa al subir un tag v*. Valida la versión, ejecuta las comprobaciones de la CLI, inspecciona el contenido de npm, publica el paquete y crea la GitHub Release con notas generadas a partir de su sección del changelog. La excepción es el tag de arranque v1.0.0, detallado abajo.

Configuración única antes de la primera publicación

1. Inicia sesión en npm con la cuenta propietaria de soymanolo y activa 2FA.

2. Crea el paquete público @soymanolo/create-my-saas mediante la primera publicación manual. npm exige que el paquete exista antes de configurar una relación de confianza. No uses el token de npm en el repositorio ni en GitHub Actions.

3. En npm, abre Packages → @soymanolo/create-my-saas → Settings → Trusted Publisher y registra GitHub Actions con estos valores:

   Campo	Valor
   Organización o usuario	LAKBAST
   Repositorio	create-my-saas
   Workflow	publish.yml
   Environment	dejar vacío
   Acción permitida	npm publish

   Esta relación usa credenciales OIDC de corta duración. El workflow necesita id-token: write para solicitarlas, pero no guarda credenciales de npm.

4. Verifica que el paquete con scope @soymanolo sea público. El workflow ejecuta npm publish sin --access public; no convierte un paquete privado en público. Tras trasladar el repositorio, revisa que la relación de confianza de npm use el propietario LAKBAST.

El siguiente procedimiento corresponde al arranque histórico de 1.0.0 y no debe repetirse para una versión ya publicada. La primera publicación manual del paquete con scope se realiza desde la raíz de un checkout limpio de esa versión:

npm login
npm publish --access public

No copies el token de npm a este repositorio, a secretos de GitHub ni a un chat. Después de esa publicación inicial, configura el proveedor de confianza y crea el tag v1.0.0. El workflow confirma que 1.0.0 ya existe en npm y crea la GitHub Release sin volver a publicar. Desde 1.0.1, las publicaciones serán automáticas.

Crear una release

Publica una nueva versión solo si cambia el contrato público de extensiones o si hay mejoras reales en las plantillas públicas. No publiques una versión por cambios internos que no afecten a esos dos ámbitos.

1. Elige una nueva versión SemVer, actualiza version en package.json y packages/cli/package.json, y añade su sección en CHANGELOG.md. El workflow usará el contenido de esa sección como descripción de la GitHub Release.

2. Ejecuta localmente las mismas comprobaciones:

   pnpm install --frozen-lockfile
   pnpm run validate:templates
   pnpm test
   npm pack --dry-run

3. Integra el cambio de versión en main y crea el tag anotado con esa misma versión:

   git tag -a vX.Y.Z -m "Release vX.Y.Z"
   git push origin vX.Y.Z

4. El workflow Publish CLI comprueba que X.Y.Z coincide exactamente con package.json. Si las verificaciones pasan, publica @soymanolo/create-my-saas con la etiqueta latest y crea la GitHub Release vX.Y.Z.

No reutilices ni muevas tags publicados: npm no permite reemplazar una versión existente. Para corregir una release, publica una nueva versión SemVer.

Verificación posterior

Comprueba la versión publicada e instala la CLI sin usar el checkout:

npm view @soymanolo/create-my-saas version
npx @soymanolo/create-my-saas@latest example-saas --backend nestjs --frontend nextjs

La configuración efectiva de Trusted Publishing y la procedencia del paquete se comprueban en npm y en el resultado de la publicación; el código del workflow por sí solo no confirma que esa relación externa esté configurada.