Decidimos no seguir esperando el linter perfecto: migración a ESLint V9 y adopción híbrida de Biome

Compartimos la experiencia del capítulo de frontend de Lemonbase al migrar a V9 para responder al fin de soporte de ESLint V8 y resolver los problemas de rendimiento mediante una adopción híbrida de Biome.

Contexto de adopción

• En septiembre de 2024 se anunció el fin de soporte de ESLint V8, y migrar a V9 se volvió indispensable para seguir recibiendo parches de seguridad y correcciones de errores
• Desde V9, la configuración basada en .eslintrc.js quedó obsoleta y Flat Config pasó a ser la opción predeterminada
• Había que revisar la compatibilidad de cerca de 400 reglas, una estructura de archivos de configuración dividida en dos y varios plugins

Proceso de migración

• La herramienta oficial de migración de ESLint se limitaba básicamente a envolver con @eslint/compat, por lo que no cumplió las expectativas
• Se generó un borrador con herramientas de IA, pero aparecieron muchas reglas omitidas y problemas de compatibilidad
• Al final, se hizo una revisión completa comparando una por una las reglas de V8 y V9 en una hoja de cálculo

Problemas de rendimiento tras la migración

• Después de subir a V9, en lugar de mejorar, pasó de 154 segundos a 184 segundos, es decir, 30 segundos más lento
• La regla import/no-cycle se volvió 10 veces más lenta que en V8 y llegó a representar el 45.8% del total
• La regla prettier/prettier también representaba el 10.2%, y la sobrecarga del doble parseo se convirtió en un cuello de botella

Adopción híbrida de Biome

• En vez de un reemplazo total, se cambió a un enfoque de “usar ambos y concentrarse en los beneficios”
• Se reemplazó Prettier por Biome Formatter, reduciendo el formateo de 14 segundos a 2 segundos
• ESLint quedó a cargo solo de las reglas personalizadas del proyecto

Resultado final

• ESLint V8: 154 segundos → ESLint V9: 184 segundos
• Solo ESLint → híbrido Biome + ESLint: ~20 segundos

Lecciones aprendidas

• Al dejar una migración en manos de IA, primero hay que hacer que proponga un plan, luego revisarlo manualmente y definir con claridad los criterios de éxito (por ejemplo, que el resultado coincida con V8)
• En vez de esperar una herramienta perfecta, a veces el camino más rápido es combinar bien las herramientas que ya se pueden usar ahora

Puntos a tener en cuenta

• Si se usan las dos herramientas juntas, hay que mantener tanto eslint.config.mjs como biome.json, y existe la posibilidad de conflictos entre reglas
• Conviene definir claramente qué reglas le corresponden a cada herramienta y explicar esa división de responsabilidades al incorporar nuevos integrantes al equipo

[selene]

Parece un texto que puede dar buenos insights a quienes todavía están lidiando con problemas de rendimiento en el linting.

Nosotros también tuvimos la experiencia de reducir un linting que tardaba más de 200 segundos a menos de 15 segundos, después de mejorar el uso híbrido de oxc (oxlint) y ESLint el año pasado.

Yo también al principio hice la migración de forma bastante bruta con IA, pero como seguían apareciendo reglas omitidas o alteradas, estuve pensando en revisarlas una por una.
Entonces hice con IA un script para extraer las reglas compatibles con oxc, y al dejar activadas en ESLint solo las reglas que oxc no soporta, ahora también se volvió mucho más fácil ir actualizando periódicamente las reglas nuevas que se van incorporando en oxc...

Al inicio ese proceso estaba semiautomatizado, pero ahora lo definimos como un Skill y basta con ejecutarlo con Claude Code, así que también quedó mucho menos pesado.

[chamchi]

¿No han pensado en probar oxlint y oxfmt en lugar de eslint y prettier?
Manteniendo una correspondencia 1 a 1 en la configuración, la velocidad aumenta al menos varias decenas de veces.