Lección 4 de 410 min
Calidad estática: ESLint, Prettier y SonarQube
Encontrar errores sin ejecutar el código, formatear de forma automática y vigilar la calidad del proyecto.
La revisión de un merge request acumula veinte comentarios: comillas simples o dobles, punto y coma sí o no, una variable que no se usa. Mientras se discute el formato, un == que compara un número con un texto pasa desapercibido y llega a producción.
La calidad estática consiste en revisar el código sin ejecutarlo, con herramientas que lo leen y avisan de errores, malas prácticas y problemas de seguridad. En esta lección verás qué hace cada tipo de herramienta y cómo encajan ESLint, Prettier y SonarQube.
Analizar sin ejecutar
Análisis estático: cuatro herramientas distintas
Linter, formateador, comprobador de tipos y SAST: cada uno busca una cosa distinta.
Un linter busca patrones de código problemáticos: variables sin usar, comparaciones con ==, promesas que nadie espera. Un formateador solo cambia el aspecto (espacios, comillas, saltos de línea) sin alterar lo que hace el código. Un comprobador de tipos, como tsc de TypeScript, verifica que los datos encajan con sus tipos.
El SAST (Static Application Security Testing, pruebas de seguridad estáticas) busca vulnerabilidades: inyecciones SQL, secretos escritos en el código o datos del usuario que llegan sin limpiar a un lugar peligroso. Conecta con lo que viste en el módulo de seguridad web, y plataformas como GitLab lo incluyen en sus pipelines.
Todas trabajan sin ejecutar nada, así que son rápidas y pueden correr en el editor mientras escribes. No sustituyen a las pruebas: detectan errores de forma, no si el cálculo del IVA es correcto.
Úsalo cuando
En todos los proyectos, desde el primer día: configurarlas al principio cuesta minutos; añadirlas a un proyecto con miles de avisos acumulados cuesta semanas.
Ten en cuenta
Cada herramienta tiene su terreno: no uses el linter para el formato ni esperes que el formateador encuentre errores. Y un aviso que todo el mundo ignora es ruido: desactiva las reglas que no aportan.
// Cuatro herramientas, cuatro avisos distintos sobre el mismo código
function buscarPedido(db, id) { // tsc: «db» e «id» tienen tipo any implícito
if (id == null) return // ESLint (eqeqeq): usa === en lugar de ==
const sinUsar = 42 // ESLint (no-unused-vars): variable sin usar
return db.query("SELECT * FROM pedidos WHERE id = " + id) // SAST: posible inyección SQL
} // Prettier: añadiría los puntos y comaEn tu editor y en cada commit
ESLint y Prettier son la pareja más habitual en proyectos de JavaScript y TypeScript: uno encuentra problemas y el otro deja el formato uniforme.
ESLint
El linter estándar de JavaScript y TypeScript, configurable con reglas y plugins.
- Desde:
- 2013
- Configuración:
- eslint.config.js
ESLint analiza tu código y aplica reglas, cada una con un nivel: off, warn o error. Las hay para errores probables (no-undef, no-unused-vars), para buenas prácticas (eqeqeq) y muchas más gracias a los plugins. Bastantes reglas se corrigen solas con eslint --fix.
Se configura con el formato plano (flat config) en un archivo eslint.config.js: una lista de objetos de configuración que se aplican en orden. Es el formato por defecto en las versiones recientes; el antiguo .eslintrc está obsoleto.
Para TypeScript se usa typescript-eslint, que permite a ESLint entender los tipos y añade reglas propias, como detectar promesas que nadie espera. En Angular, angular-eslint aporta reglas para componentes y también revisa las plantillas HTML.
Úsalo cuando
En cualquier proyecto de JavaScript o TypeScript, integrado en el editor para ver los avisos al escribir y en el pipeline para que nada pase sin revisar.
Ten en cuenta
Las cuestiones de estilo (espacios, comillas) déjaselas a Prettier: si las dos herramientas opinan sobre el formato, se contradicen. Y si activas muchas reglas de golpe en un proyecto existente, empieza con warn y ve endureciendo.
import { defineConfig } from "eslint/config";
import js from "@eslint/js";
import tseslint from "typescript-eslint";
import prettier from "eslint-config-prettier";
export default defineConfig([
js.configs.recommended,
tseslint.configs.recommended,
{
rules: {
eqeqeq: "error", // obliga a usar === en lugar de ==
"no-console": "warn",
},
},
prettier, // al final: apaga las reglas que chocarían con Prettier
]);Prettier
Un formateador con opiniones: reescribe el código siempre igual y acaba con los debates.
- Desde:
- 2017
- Tipo:
- formateador
Prettier no corrige tu formato: lo descarta. Lee el código, lo convierte en un árbol y lo vuelve a escribir según sus propias reglas, sin importar cómo estaba. El resultado es idéntico lo escriba quien lo escriba.
Tiene muy pocas opciones a propósito (ancho de línea, tipo de comillas, punto y coma, comas finales): la idea es que el equipo deje de discutir de estilo y lo delegue en la herramienta. Formatea JavaScript, TypeScript, CSS, HTML, JSON, YAML, Markdown y más. Lo normal es activarlo al guardar en el editor y comprobarlo en el pipeline con prettier --check.
Para que no choque con ESLint, se añade eslint-config-prettier al final de la configuración de ESLint: desactiva las reglas de estilo que se pelearían con Prettier.
Úsalo cuando
En todos los proyectos con más de una persona. Configúralo al principio para no tener que reformatear todo el código de golpe más adelante.
Ten en cuenta
Reformatear un proyecto existente genera un diff enorme: hazlo en un commit aparte para no mezclarlo con cambios reales. Existen alternativas más rápidas, como Biome, que reúne linter y formateador en una sola herramienta.
// Antes: cada persona escribe a su manera
const usuario={nombre:'Ana',edad:30,
roles:[ 'admin','editor' ]}
// Después: siempre igual, lo escriba quien lo escriba
const usuario = { nombre: "Ana", edad: 30, roles: ["admin", "editor"] };Nota
Estas herramientas rinden más en tres sitios a la vez: en el editor, para ver los avisos mientras escribes; en el pre-commit, con Husky y lint-staged, como viste en el módulo de CI/CD; y en el pipeline, como filtro final que nadie puede saltarse.
La calidad de todo el proyecto
SonarQube
Inspección continua del proyecto: errores, vulnerabilidades, deuda técnica y quality gates.
- Creado por:
- SonarSource
- En la nube:
- SonarQube Cloud
SonarQube analiza todo el proyecto en cada push o merge request, en muchos lenguajes, y guarda su evolución en un panel. Clasifica los problemas en bugs (código que probablemente falla), vulnerabilidades (fallos de seguridad), code smells (código que funciona, pero será difícil de mantener) y puntos de seguridad sensibles que alguien debe revisar.
Calcula la deuda técnica, una estimación del tiempo necesario para resolver los problemas de mantenimiento, y muestra la cobertura de pruebas y el código duplicado. La cobertura no la mide él: lee el informe que generan tus pruebas.
Su pieza clave es el quality gate: un conjunto de condiciones, como «ningún problema grave nuevo» o «al menos un 80 % de cobertura en el código nuevo», que el análisis cumple o no. Si no las cumple, el pipeline puede bloquear el merge. Su extensión para el editor (antes SonarLint, hoy SonarQube for IDE) muestra los mismos avisos mientras escribes.
Úsalo cuando
En proyectos medianos o grandes, o en organizaciones que quieren un criterio de calidad común para muchos equipos y repositorios.
Ten en cuenta
Necesita un servidor (o su versión en la nube, SonarQube Cloud), y algunas funciones, como analizar ramas y merge requests, dependen de la edición. Una cifra de deuda técnica no es una verdad absoluta: úsala para ver tendencias, no para señalar a nadie.
# Identifica el proyecto en el servidor de SonarQube
sonar.projectKey=tienda-web
sonar.sources=src
sonar.exclusions=**/*.test.ts
# SonarQube no ejecuta tus pruebas: lee su informe de cobertura
sonar.javascript.lcov.reportPaths=coverage/lcov.info
# Espera al resultado del quality gate y hace fallar el pipeline si no se cumple
sonar.qualitygate.wait=trueInteractivo
Qué hace cada herramienta
Activa o desactiva opciones para compararlas cara a cara.
| Característica | ESLint | Prettier | TypeScript (tsc) |
|---|---|---|---|
| Qué busca | Errores probables y malas prácticas | Formato inconsistente | Tipos que no encajan |
| Corrige sola | Parte de los problemas, con --fix | Sí, todo | No |
| Ejemplo de aviso | «total tiene un valor asignado, pero nunca se usa» | Ninguno: reescribe el archivo | «El tipo 'string' no se puede asignar al tipo 'number'» |
| Dónde se ejecuta | Editor, pre-commit y pipeline | Editor al guardar, pre-commit y pipeline con --check | Editor y pipeline |
| Configuración | eslint.config.js | .prettierrc, con muy pocas opciones | tsconfig.json |
Ponlo en práctica
Saber qué es cada cosa es la mitad del trabajo. La otra mitad es reconocer cuándo usarla.
Interactivo
¿Qué usarías?
Lee cada situación y elige la opción que mejor la resuelve. Fallar aquí no cuenta: es para practicar.
Las revisiones de código se llenan de comentarios sobre comillas, sangrías y dónde partir las líneas.
Para recordar
- Linter, formateador, comprobador de tipos y SAST buscan cosas distintas y se complementan.
- ESLint encuentra problemas con reglas y plugins, configurado en
eslint.config.js; Prettier deja el formato uniforme y termina con los debates de estilo. - Con
eslint-config-prettier, cada herramienta se ocupa de lo suyo sin pelearse con la otra. - SonarQube vigila la calidad de todo el proyecto, y sus quality gates pueden bloquear un merge que la empeore.
Comprueba lo aprendido
Cuestionario
Responde las 5 preguntas para completar la lección.
1.¿Qué diferencia hay entre un linter y un formateador?
2.¿Para qué sirve
eslint-config-prettier?3.¿Qué es un quality gate en SonarQube?
4.¿En qué archivo se configura ESLint con el formato actual?
5.SonarQube muestra un 0 % de cobertura aunque tu proyecto tiene pruebas. ¿Qué es lo más probable?