Configura Husky y Commitlint en tu Repositorio

A veces, ponemos cualquier cosa en nuestros commits de código, pero esto no ayuda cuando verificamos qué cambios se hicieron, si fue una corrección o parte de una nueva funcionalidad. Mantener el orden en nuestros repositorios es importante. Herramientas como Husky y Commitlint nos ayudan a agregar estructura a nuestro trabajo. Te mostraré cómo usar estas herramientas para hacer esta tarea más organizada.

Husky

Husky es una herramienta para desarrolladores que funciona con Git. Es como un guardia: cuando haces un "commit" (guardar cambios en tu código), Husky verifica si todo sigue las reglas que estableciste (como el estilo de código o las pruebas). Si algo no está bien, Husky lo detiene hasta que lo corrijas. Esto ayuda a mantener tu código limpio y sin errores antes de guardarlo permanentemente.

Instala Husky con yarn

yarn add --dev husky

Inicia la configuración

npx husky init

Esto crea el archivo .husky/pre-commit y lo agrega a nuestro package.json en la sección de scripts:

"scripts": {
    "prepare": "husky" // <- agregado automáticamente
}

En nuestro caso, prepare no funciona con yarn, así que lo cambiaremos de prepare a postinstall, quedando así:

 "scripts": {
    "start": "nx serve",
    "build": "nx build",
    "test": "nx test",
    "postinstall": "husky" // <- usamos yarn
  },

La magia viene del archivo .husky/pre-commit, que puedes pensar como un archivo bash, donde cada línea es un comando que se ejecutará. En nuestro caso, antes de cada commit, queremos ejecutar:

• nx format:write

• nx affected -t lint,test --parallel=2

Con esto, nos aseguramos de que antes de hacer un commit, nuestros archivos afectados estén formateados, y luego verifica el lint y se asegura de que todas las pruebas se ejecuten perfectamente.

Ahora, cuando hacemos un commit, sucede algo como esto:

Genial, ahora tenemos Husky instalado y configurado. Si algo sale mal, el commit no se ejecutará, dándonos la oportunidad de corregir el lint o las pruebas localmente (en lugar de descubrirlo a través de la GitHub Action).

Commit Lint

Commitlint es una herramienta de desarrollo de software que garantiza que los mensajes de commit (los registros de cambios de código) sigan un formato determinado. Funciona como un verificador automático, mirando cada mensaje de commit antes de que se confirme. Esto ayuda a mantener el historial de cambios del proyecto claro y consistente.

Instalamos commitlint

yarn add -d @commitlint/{config-conventional,cli}

Creamos el archivo de configuración:

echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js

Husky + Commitlint

Para que Husky detecte el commit, agregaremos otro Git hook (tal como hicimos con pre-commit), en este caso, es commit-msg. Crearemos un archivo en .husky/commit-msg y agregaremos lo siguiente:

npx --no -- commitlint --edit ${1}

Ahora, cuando intentamos hacer un commit simple y no tiene el formato correcto, vemos algo como esto:

Así que el commit no pasa porque no tiene el formato correcto.

Pero ¿cuál es el formato correcto? Bueno, commitlint sigue algo llamado formato de commit convencional, que espera un mensaje de commit con el formato [optional scope]:

Por defecto, tenemos estos tipos: build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test

Por ejemplo, si queremos definir la lista de tipos y ámbitos a usar, podemos modificar el archivo de configuración commitlint.config.js con algo como esto:

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [
      2,
      'always',
      ['feat', 'fix', 'docs', 'style', 'refactor', 'test', 'chore'],
    ],
    'scope-enum': [
      2,
      'always',
      ['api', 'frontend', 'backend', 'ui', 'database'],
    ],
  },
};

Qué hacen las rules agregadas:

• 'type-enum': [2, 'always', ['feat', 'fix', 'docs', 'style', 'refactor', 'test', 'chore']]: Esto define los tipos de commit permitidos. Los tipos personalizados aquí son feat, fix, docs, style, refactor, test y chore. Estos representan diferentes tipos de cambios que podrías hacer en tu proyecto (nuevas funcionalidades, correcciones, documentación, etc.).

• 'scope-enum': [2, 'always', ['api', 'frontend', 'backend', 'ui', 'database']]: Aquí, además de los ámbitos api, frontend y backend, agregamos ui y database como ámbitos válidos.

• El 2 significa que esta es una regla que siempre debe seguirse (error si no se cumple), y always indica que esta regla está siempre activa.

Con esta configuración, un mensaje de commit debe usar uno de los tipos definidos y uno de los ámbitos definidos. Por ejemplo:

git commit -m "feat(ui): add new button component"

Este mensaje indica que se está agregando una nueva funcionalidad (feat) relacionada con la interfaz de usuario (ui).

Si estás usando Angular puedes usar esta (enlace) configuración por defecto, o Nx, este enlace para obtener todos los ámbitos de tus aplicaciones Nx y generar dinámicamente los scopes.

Conclusión

Husky y Commitlint son herramientas útiles para mantener la calidad del código y la consistencia en un proyecto. Husky verifica el código contra las reglas antes de un commit, mientras que Commitlint se asegura de que los mensajes de commit sigan un formato específico. Esto mantiene el historial de cambios del proyecto claro y consistente. Al usar estas herramientas en tu proceso de desarrollo, puedes evitar errores, aplicar el estilo de código y mantener un historial de commits limpio. Esto mejora la legibilidad y hace que el trabajo en equipo sea más eficiente.

Recursos

• husky doc:https://typicode.github.io/husky/

• commitlint doc: https://commitlint.js.org/#/

• Conventional Commits: https://conventionalcommits.org/