Husky y lint-staged (Ganchos de pre-commit)
Ejecuta ESLint y Prettier automáticamente en los archivos staged antes de cada commit para detectar problemas temprano.
Busca en todas las páginas de la documentación
Ejecuta ESLint y Prettier automáticamente en los archivos staged antes de cada commit para detectar problemas temprano.
🤖 Read the SystemsArchitect.io Blog for over 100+ cloud architecture articles 🔥
Tarjeta de referencia rápida - lista para copiar y pegar.
# Instala husky y lint-staged
npm install --save-dev husky lint-staged
# Inicializa husky
npx husky init
# El comando init crea .husky/pre-commit
# Edítalo para ejecutar lint-staged
echo "npx lint-staged" > .husky/pre-commitCuándo usarlo: Cualquier proyecto en equipo donde quieras garantizar que el código cometido pase los controles de linting y formateo.
# .husky/pre-commit
npx lint-staged// package.json
{
"scripts": {
"lint": "next lint",
"format": "prettier --write .",
"prepare": "husky"
},
"lint-staged": {
"*.{ts,tsx}": [
"eslint --fix --no-warn-ignored",
"prettier --write"
],
"*.{css,json,md}": [
"prettier --write"
]
}
}Lo que demuestra esto:
git add)prepare asegura que husky se instale automáticamente después de npm install.husky/pre-commit) para ejecutar comandos antes de cada commitgit diff --staged y los pasa a los comandos configuradosprepare se ejecuta después de npm install, asegurando que los ganchos estén configurados para cada desarrolladorCon Biome en lugar de ESLint + Prettier:
{
"lint-staged": {
"*.{ts,tsx,js,jsx,json,css}": [
"biome check --write --no-errors-on-unmatched"
]
}
}Con revisión de tipos (más lento pero exhaustivo):
{
"lint-staged": {
"*.{ts,tsx}": [
"eslint --fix --no-warn-ignored",
"prettier --write"
]
}
}# .husky/pre-commit
npx lint-staged
npx tsc --noEmitNota: tsc --noEmit revisa el proyecto completo, no solo los archivos staged, porque TypeScript necesita el contexto completo del proyecto.
Linting de mensajes de commit con commitlint:
npm install --save-dev @commitlint/cli @commitlint/config-conventional
echo "npx commitlint --edit \$1" > .husky/commit-msg// commitlint.config.js
export default { extends: ["@commitlint/config-conventional"] };Omitiendo ganchos (escotilla de escape):
# Cuando realmente necesitas eludir (depuración, commits WIP)
git commit --no-verify -m "WIP: trabajo en progreso"// lint-staged pasa rutas de archivo a ESLint, que funciona con
// archivos TypeScript sin problemas siempre que @typescript-eslint
// esté configurado.
// Nota: ESLint --fix puede corregir automáticamente algunos problemas de TypeScript:
// - Eliminar importaciones no utilizadas
// - Agregar la palabra clave `type` a importaciones solo de tipos
// - Corregir violaciones de consistent-type-importsCosas que te van a morder. Cada gotcha incluye qué sale mal, por qué sucede y la solución.
Los ganchos no se ejecutan después de clonar - Los ganchos de Git no se cometieron al repo; viven en .git/hooks/. Los nuevos desarrolladores deben ejecutar npm install (que dispara prepare). Solución: Asegúrate de que "prepare": "husky" esté en tus scripts de package.json.
Advertencias de ESLint en archivos ignorados - Cuando lint-staged pasa rutas de archivo a ESLint, los archivos que coinciden con tus ignorados de ESLint disparan advertencias. Solución: Agrega la flag --no-warn-ignored al comando de ESLint en la configuración de lint-staged.
Problemas de staging parcial - Si revistes solo parte de un archivo (git add -p), lint-staged opera en el archivo completo, que puede incluir cambios no staged. Solución: Ten conocimiento de esta limitación. Para casos críticos, reviste el archivo completo.
Ganchos de pre-commit lentos - Ejecutar revisión de tipos (tsc) en cada commit puede tomar 10 o más segundos en proyectos grandes. Solución: Ejecuta tsc solo en CI. Mantén los ganchos de pre-commit rápidos limitándolos a ESLint y Prettier en archivos staged.
CI no ejecuta ganchos - Los ganchos de Git son solo locales. Los entornos de CI no ejecutan ganchos de pre-commit. Solución: Siempre ejecuta linting y controles de formateo en CI como red de seguridad. Ver Linting en CI/CD.
Otras formas de resolver el mismo problema - y cuándo cada una es la mejor opción.
| Alternativa | Úsalo Cuando | No lo Uses Cuando |
|---|---|---|
lefthook | Quieres ganchos más rápidos con ejecución paralela, escrito en Go | Husky + lint-staged funciona bien para tu proyecto |
| Linting solo en CI | No quieres ralentizar los commits locales | Quieres retroalimentación instantánea antes de hacer push |
nano-staged | Quieres una alternativa más pequeña y rápida a lint-staged | Necesitas características avanzadas de lint-staged como resolvers personalizados |
| VS Code format-on-save | Desarrollador solo, sin CI | Proyectos en equipo donde la consistencia debe ser reforzada |
npm install.npx husky init.git diff --staged (archivos que has git add-ado).git commit --no-verify -m "WIP: trabajo en progreso"Úsalo con moderación para depuración o commits WIP. CI seguirá atrapando problemas.
.git/hooks/, que no se comete al repo.npm install, que dispara el script prepare."prepare": "husky" esté en tus scripts de package.json.# .husky/pre-commit
npx lint-staged
npx tsc --noEmittsc --noEmit revisa el proyecto completo, no solo los archivos staged.tsc solo en CI para mantener los ganchos rápidos.{
"lint-staged": {
"*.{ts,tsx,js,jsx,json,css}": [
"biome check --write --no-errors-on-unmatched"
]
}
}npm install --save-dev @commitlint/cli @commitlint/config-conventional
echo "npx commitlint --edit \$1" > .husky/commit-msgEsto refuerza mensajes de commit convencionales como feat:, fix:, docs:.
git add manualmente archivos después de auto-fix de ESLint o Prettier.--no-warn-ignored al comando de ESLint en tu configuración de lint-staged.type a importaciones solo de tipos.consistent-type-imports.import/order.Revisado por Chris St. John·Última actualización: 16 jul 2026
🤖 Read the SystemsArchitect.io Blog for over 100+ cloud architecture articles 🔥