Prettier

¿Qué es Prettier?

Prettier es un formateador de código opinionated. Analiza tu código para convertirlo en un árbol de sintaxis y lo vuelve a imprimir con un diseño determinista, ignorando los espacios en blanco que hayas escrito. El resultado depende únicamente de la estructura del código y de un pequeño conjunto de opciones, por lo que la misma entrada siempre produce la misma salida.

Ese determinismo es precisamente el objetivo. Las discusiones sobre el estilo desaparecen porque es el formateador quien decide, no el equipo. Los diffs se reducen a los cambios reales en lugar de ruido por espacios, y los revisores dedican su tiempo a la lógica y al diseño. Prettier es una de las pocas herramientas que reduce mediblemente la fricción en una base de código.

Configuración

Prettier funciona sin necesidad de configuración, pero puedes definir algunas opciones en .prettierrc.

{
  "semi": true,
  "singleQuote": false,
  "trailingComma": "all",
  "printWidth": 100,
  "tabWidth": 2,
  "arrowParens": "always"
}

Estas son las opciones que la mayoría de los equipos suelen ajustar. Más allá de ellas, Prettier toma las decisiones. Cuantas menos opciones configures, más consistente será el resultado entre proyectos y menos mantenimiento requerirá.

Ejecutando Prettier

Formatea los archivos directamente o verifica los cambios sin escribirlos.

npx prettier --write .
npx prettier --check .
npx prettier --write src/app.tsx

--write reformatea y guarda; --check informa sobre los archivos que cambiarían y sale con un código distinto de cero, que es exactamente lo que necesita la CI. Añade un script para que los comandos sean consistentes.

{
  "scripts": {
    "format": "prettier --write .",
    "format:check": "prettier --check ."
  }
}

Ignorar archivos

.prettierignore enumera las rutas que se deben omitir, utilizando la misma sintaxis que .gitignore.

dist
coverage
pnpm-lock.yaml
*.generated.ts

Ignorar la salida de compilación y los archivos generados es importante: formatearlos genera ruido que la siguiente compilación sobrescribirá, e incluso puede romper la generación de código que espera una estructura específica.

Integración con el editor

Instala la extensión de Prettier para tu editor y activa la opción de formatear al guardar (format on save). Aquí es donde Prettier demuestra su mayor valor: no tienes que pensar en el formato y cada vez que guardas, el archivo queda limpio. Esto también significa que puedes usar --check en CI con total confianza, ya que el formateo ocurre de manera continua en lugar de hacer una limpieza masiva al final.

Trabajando con ESLint

Prettier y ESLint se solapan en cuanto a reglas de estilo y, si se dejan solos, entrarán en conflicto. La solución estándar es dejar que Prettier se encargue del formateo y desactivar las reglas de ESLint que causen conflictos.

// eslint.config.js
import js from "@eslint/js";
import prettier from "eslint-config-prettier";

export default [js.configs.recommended, prettier];

eslint-config-prettier desactiva todas las reglas de ESLint que podrían entrar en conflicto con Prettier, de modo que ESLint se centre en la calidad del código y Prettier en el diseño. Si prefieres que los problemas de formateo aparezcan como errores de lint, eslint-plugin-prettier ejecuta Prettier como una regla, aunque muchos equipos prefieren mantener ambos procesos separados.

Pre-commit hooks

Formatear el código antes de un commit mantiene la CI en verde y el historial limpio.

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx,css,md}": "prettier --write"
  }
}

Combinado con un hook runner como husky, esto formatea únicamente los archivos en el stage, por lo que los commits siguen siendo rápidos. Es una configuración sencilla que evita toda una categoría de comentarios de revisión sobre “código sin formatear”.

Dónde encaja Prettier

Prettier se encarga únicamente del formateo. No busca errores, no impone tipos ni verifica las importaciones; esas tareas corresponden a ESLint y al comprobador de tipos. Un toolchain saludable ejecuta los tres: Prettier para el diseño, ESLint para la calidad y TypeScript para los tipos. Cada uno tiene una función específica y ninguno entra en conflicto con los demás.

Mejores prácticas

• Acepta los valores predeterminados a menos que tu equipo tenga una razón sólida para cambiar alguno.
• Haz commit de un .prettierrc para que todos los editores y las ejecuciones de CI estén sincronizados.
• Añade .prettierignore para la salida de build y los archivos generados.
• Configura el editor para formatear al guardar.
• Ejecuta --check en CI y --write en un pre-commit hook.
• Desactiva las reglas de ESLint que entren en conflicto mediante eslint-config-prettier.
• Mantén la lista de opciones corta.

Errores comunes

• Permitir que ESLint y Prettier formateen el código al mismo tiempo y entren en conflicto.
• Formatear archivos generados automáticamente, creando diffs ruidosos.
• Omitir la verificación en el CI, permitiendo que se fusionen cambios con código sin formatear.
• Cambiar las opciones en cada proyecto sin motivo, perdiendo la consistencia entre proyectos.
• Ejecutar Prettier en todo el repositorio mediante un pre-commit hook, ralentizando los commits.
• Usar Prettier para imponer reglas semánticas que corresponden a ESLint.

Próximos pasos

Prettier elimina por completo toda una categoría de tareas repetitivas. Combínalo con ESLint para asegurar la calidad, TypeScript para obtener seguridad de tipos, e integra ambos en tu proyecto de Vite y en tu CI. Después, configura el formateo al guardar y no vuelvas a preocuparte por los espacios.