Prettier y ESLint: configuración mínima que evita discusiones

Un equipo de desarrollo gasta horas discutiendo si usar comillas simples o dobles, si una línea debe tener 80 o 120 caracteres, o si una coma colgante es aceptable. Ese tiempo es dinero y energía que no se dedica a resolver problemas reales del negocio. La solución es simple y no negociable: una configuración automática de formato y linting.

Lo que hago en todos mis proyectos, tanto propios como para clientes, es establecer una configuración mínima de Prettier y ESLint. Esto elimina la subjetividad, asegura consistencia y permite que el equipo se enfoque en la lógica del negocio.

Prettier como fuente única de formato

Prettier es un formateador de código, no un linter. Su trabajo es tomar tu código y reescribirlo siguiendo unas reglas de estilo predefinidas. Mi regla es que Prettier sea la fuente única de verdad para el formato.

Esto significa que no hay opciones para el formato en ESLint o en el editor — Prettier se encarga de todo lo estético. La configuración que uso es mínima, enfocada en la consistencia y la legibilidad.

// .prettierrc.json
{
  "semi": true,
  "trailingComma": "all",
  "singleQuote": true,
  "printWidth": 100,
  "tabWidth": 2,
  "endOfLine": "lf"
}

Estos son los puntos que considero clave para que el código sea legible y predecible. Las comillas simples, las comas al final de cada elemento en listas (trailing comma) y un ancho de línea de 100 caracteres son mis estándares. Esto ya reduce el ruido mental al leer cualquier base de código.

ESLint para prevenir errores lógicos y malas prácticas

ESLint es el linter. Su función no es formatear, sino identificar patrones de código que son problemáticos, potencialmente errores o malas prácticas. Aquí es donde ponemos las reglas que realmente importan para la calidad y la robustez del software.

Mi configuración de ESLint parte de la base de las recomendaciones de Airbnb, que son un buen punto de partida. Luego añado o sobrescribo reglas según las necesidades del proyecto o las decisiones de arquitectura. Por ejemplo, siempre fuerzo el uso estricto de === y !== para evitar errores de coerción de tipos en JavaScript.

// .eslintrc.json
{
  "env": {
    "browser": true,
    "es2021": true,
    "node": true
  },
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier"
  ],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaVersion": "latest",
    "sourceType": "module"
  },
  "plugins": [
    "react",
    "@typescript-eslint"
  ],
  "rules": {
    "indent": ["error", 2],
    "linebreak-style": ["error", "unix"],
    "quotes": ["error", "single"],
    "semi": ["error", "always"],
    "eqeqeq": ["error", "always"],
    "no-console": "warn",
    "no-unused-vars": "off",
    "@typescript-eslint/no-unused-vars": ["warn", { "argsIgnorePattern": "^_" }]
  },
  "settings": {
    "react": {
      "version": "detect"
    }
  }
}

ESLint y Prettier no deben pisarse. Para eso, la configuración de ESLint debe extender prettier. Esto deshabilita todas las reglas de formato de ESLint que puedan entrar en conflicto con Prettier.

El tradeoff honesto: Lo que ganas y lo que complicas

Implementar esta configuración tiene beneficios claros y algunas complejidades que hay que asumir.

Lo que ganas:

• Consistencia de código: Todos los miembros del equipo escriben con el mismo estilo, sin importar su editor o preferencias personales. Esto mejora la legibilidad y mantenibilidad del código.
• Reducción de conflictos en merges: Al tener el código formateado de forma idéntica, los conflictos en Git por cambios de estilo desaparecen.
• Detección temprana de errores: ESLint atrapa problemas antes de que lleguen a producción o incluso a un code review.
• Code reviews más eficientes: El feedback se centra en la lógica y la arquitectura, no en el estilo.

Lo que complicas:

• Curva de aprendizaje inicial: Configurar ambos por primera vez puede ser un poco tedioso, especialmente si hay que integrar TypeScript o frameworks específicos.
• Actualizaciones: Mantener las dependencias y configuraciones al día requiere atención, ya que las reglas y plugins evolucionan.
• Configuración de IDEs: Cada desarrollador debe configurar su IDE para que use Prettier y ESLint en “guardar”, aunque esto ya es casi estándar.

Automatización en cada commit

Una vez configurado, el siguiente paso es asegurar que nadie pueda subir código que no cumpla con las reglas. Para esto, uso Git hooks con husky y lint-staged. Antes de cada commit, lint-staged ejecuta Prettier y ESLint solo sobre los archivos modificados.

Esto garantiza que solo el código que se va a subir cumple con los estándares, sin necesidad de formatear todo el proyecto. Esta automatización, ligera y efectiva, evita que el problema llegue al repositorio.

// package.json (fragmento)
{
  "name": "mi-proyecto",
  "version": "1.0.0",
  "scripts": {
    "lint": "eslint . --ext .js,.jsx,.ts,.tsx",
    "lint:fix": "eslint . --ext .js,.jsx,.ts,.tsx --fix",
    "format": "prettier --write \"**/*.{js,jsx,ts,tsx,json,md}\""
  },
  "devDependencies": {
    "@typescript-eslint/eslint-plugin": "^7.0.0",
    "@typescript-eslint/parser": "^7.0.0",
    "eslint": "^8.0.0",
    "eslint-config-airbnb-base": "^15.0.0",
    "eslint-config-prettier": "^9.0.0",
    "eslint-plugin-react": "^7.0.0",
    "husky": "^9.0.0",
    "lint-staged": "^15.0.0",
    "prettier": "^3.0.0"
  },
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{json,md}": [
      "prettier --write"
    ]
  }
}

Este setup permite que los desarrolladores puedan enfocarse en su trabajo sin preocuparse por el estilo, sabiendo que las herramientas corregirán automáticamente cualquier desviación. Esta configuración es una base sólida para cualquier proyecto de software y un ejemplo de cómo la automatización de tareas con herramientas como GitHub Actions puede simplificar el día a día.

Si buscas más formas de asegurar la calidad de tu código, revisa cómo el testing automatizado ahorra dinero en el desarrollo. Y para mejorar la colaboración en equipo y mantener altos estándares, te explico el verdadero valor de un code review. Si estás evaluando decisiones de stack, mi artículo sobre TypeScript en proyectos pequeños y sus tradeoffs puede darte perspectiva.