Versionado y automatización de releases

El versionado semántico da significado a cada número de MAJOR.MINOR.PATCH. Sube PATCH (1.4.2 → 1.4.3) cuando corriges errores sin cambiar cómo se usa; MINOR (1.4.2 → 1.5.0) cuando añades funciones compatibles con lo anterior; y MAJOR (1.4.2 → 2.0.0) cuando rompes la compatibilidad. Al subir un número, los de su derecha vuelven a cero.

Ya lo viste en la lección de gestores de paquetes: gracias a esas promesas, un rango como ^1.4.2 acepta cualquier 1.x posterior, pero nunca la 2.0.0. También existen versiones previas, como 2.0.0-beta.1, que se ordenan antes de la versión final.

Las versiones 0.x son especiales: indican desarrollo inicial, en el que cualquier cosa puede cambiar. La 1.0.0 marca el momento en que la API pública se considera estable.

Conventional Commits fija el formato de la primera línea: tipo(ámbito): descripción. El tipo dice qué clase de cambio es: feat para una función nueva, fix para una corrección y otros como docs, refactor, test, perf, ci o chore. El ámbito (scope), opcional, indica la parte afectada, como en fix(carrito): ….

Un cambio incompatible se marca con ! tras el tipo (feat(api)!: …) o con un pie BREAKING CHANGE: al final del mensaje. Así, cada commit se traduce en una subida de versión: fix es un PATCH, feat un MINOR y cualquier cambio incompatible, un MAJOR.

Para que nadie se salte la convención, commitlint revisa cada mensaje. Con su configuración convencional (@commitlint/config-conventional) rechaza tipos desconocidos, el tipo en mayúsculas, descripciones vacías o terminadas en punto y también las que empiezan en mayúscula.

Semantic Release se ejecuta en el pipeline cada vez que algo llega a la rama de release. Busca la última etiqueta de Git (por ejemplo, v1.4.2), analiza los commits posteriores, calcula la versión siguiente, genera las notas de la release, crea la etiqueta v1.5.0 y publica: en npm, en GitLab, en GitHub o donde indiquen sus plugins.

No hay ningún paso humano: si se fusiona un feat, sale una versión nueva. Todo se configura con plugins (commit-analyzer, release-notes-generator, npm, gitlab…) en un archivo como .releaserc.json, y en el pipeline basta con ejecutar npx semantic-release.

Con Changesets, la versión no se deduce de los commits: la decide quien hace el cambio. Al preparar su rama ejecuta npx changeset, elige qué paquetes cambian, si es major, minor o patch, y escribe un resumen. El resultado es un archivo en la carpeta .changeset/ que viaja en el merge request y se revisa como el resto del código.

Cuando toca publicar, changeset version consume todos los changesets pendientes, sube las versiones en cada package.json, actualiza los CHANGELOG.md y ajusta las dependencias entre paquetes; después, changeset publish los publica. Brilla en monorepos como los que viste con Turborepo, porque cada paquete se versiona por separado.

Release Please, creado por Google, también calcula la versión a partir de Conventional Commits, pero no publica por su cuenta. En su lugar, abre y mantiene un pull request de release con la versión nueva y el CHANGELOG.md actualizado. Cada commit que llega a main lo actualiza.

Cuando decides publicar, fusionas ese pull request: Release Please crea la etiqueta y la release en GitHub, y los pasos siguientes de tu pipeline publican el paquete o despliegan. Admite muchos lenguajes (Node, Python, Java, Go, Rust…) y monorepos mediante un archivo de manifiesto.

Husky guarda los hooks en una carpeta .husky/ del repositorio y configura Git para que los use. Al ejecutar npx husky init, añade al package.json un script prepare que los activa automáticamente en cuanto alguien hace npm install.

Los dos hooks más útiles son pre-commit, que se ejecuta antes de crear el commit (ideal para pasar el linter), y commit-msg, que recibe el mensaje y puede rechazarlo (ideal para commitlint). Si un hook termina con error, el commit no se crea.

Pasar ESLint y Prettier por todo el proyecto en cada commit sería lento. lint-staged mira qué archivos están en la staging area y ejecuta sobre ellos los comandos que configures según su extensión. Si un comando corrige algo, como prettier --write, la corrección entra en el commit.

Combinado con el hook pre-commit de Husky, garantiza que todo lo que entra en el repositorio pasa el linter y tiene el formato correcto, y tarda segundos aunque el proyecto tenga miles de archivos. Verás ESLint y Prettier a fondo en el módulo de testing y calidad.