Análisis estático con Linter en proyectos Nx y Angular 17

Un código confiable no se logra solo con pruebas unitarias: un buen flujo incluye un análisis estático con un linter. Aquí verás cómo se ejecuta el Lint en proyectos con Nx, qué errores típicos aparecen y cómo se corrigen con prácticas actuales de Angular 17 y TypeScript para asegurar calidad y facilitar la integración continua con GitHub Actions.

¿Qué es un linter y por qué mejora tu código?

Un linter revisa el código fuente en busca de errores, problemas de estilo, malas prácticas y posibles bugs. El objetivo es claro: garantizar que el código esté escrito según buenas prácticas y evitar sorpresas en producción. Si ya tienes pruebas unitarias pasando, el siguiente paso es asegurar consistencia y tipado con Lint.

• Detecta uso de any que omite validaciones de TypeScript.
• Señala constructores cuando debe usarse inject en Angular 17.
• Marca variables declaradas y no usadas.
• Exige convenciones en componentes compartidos con prefijo lib.
• Falla si hay un solo error, obligando a corregir antes de avanzar.

¿Cómo correr el lint con Nx en todos los proyectos?

Para un proyecto puntual, se ejecuta en la terminal poniendo siempre npx primero. Al correrlo, verás warnings y errores que debes corregir antes de continuar. Si hay un solo error, el Lint falla.

npx nx lint app uno

Para correrlo en todos los proyectos, se usa npx nx run many y se indica que el target es Lint. Así, recorre todos los proyectos configurados y muestra qué falla para corregirlo en serie.

npx nx run many

• Útil cuando trabajas con varios paquetes en un monorepo con Nx.
• Permite ver un panorama completo de la calidad actual.
• Tras corregir, vuelve a ejecutarse hasta que todo pase.

¿Qué errores detectó y cómo se corrigieron?

Los errores se repiten y siguen un patrón. Al corregirlos uno por uno, el Lint termina pasando en todos los proyectos.

¿Cuándo usar inject en Angular 17?

En versiones nuevas, se reemplaza el constructor por inject para inyección de dependencias. Esto moderniza el código y evita patrones obsoletos.

// Antes
class MiComponente {
  constructor(private servicio: TipoDeServicio) {}
}

// Después
class MiComponente {
  private servicio = inject(TipoDeServicio);
}

• Mejora la compatibilidad con Angular 17.
• Hace el código más claro y alineado al estándar actual.

¿Por qué evitar any en TypeScript?

El uso de any saltea validaciones de TypeScript. Se debe especificar el tipo exacto en spec y en archivos TS para que el linter no falle y el tipado ayude de verdad.

// Antes
let servicio: any;

// Después
let servicio: TipoDeServicio;

// Ajuste de tipo cuando puede ser indefinido
let valor: unknown;

• En spec, el mock debe indicar el modelo que representa.
• Evita errores silenciosos y favorece refactors seguros.

¿Cómo estandarizar componentes compartidos con lib?

En bibliotecas compartidas, los componentes llevan el prefijo lib. Esto exige actualizar todos los usos en HTML.

<mi-componente-compartido>mi-componente-compartido>


<lib-mi-componente-compartido>lib-mi-componente-compartido>

• Asegura coherencia en toda la biblioteca.
• Evita referencias rotas entre plantillas.

Además, se aplicaron otras correcciones recurrentes:

• Eliminar variables no usadas, por ejemplo, new user ID no utilizado. Se borra.
• Ajustar outputs en botones: el estándar indica usar la acción como button click para botones. Se corrige donde aplique.
• Revisar HTML y spec para replicar cambios en todos los lugares impactados.

Tras seguir estas instrucciones y volver a ejecutar el Lint, todo pasó correctamente. Con pruebas unitarias y linting en verde, se habilita una integración continua fluida con GitHub Actions para que, ante un merge o disparador, el pipeline confirme que todo está ok.

¿Te quedó alguna duda o quieres compartir tu experiencia corrigiendo any, migrando a inject o estandarizando lib en tu monorepo con Nx? Comenta y sigamos la conversación.