El problema de aplicar correcciones automáticas en paralelo en los linters

Cuando un linter —como ESLint para JavaScript— ejecuta varias reglas con autofix en una sola pasada y aplica todas las correcciones a la vez, puede generar código roto aunque cada corrección individual sea correcta por sí sola. El autor, creador de elm-review, lo ilustra con un archivo de ejemplo: si el linter decide a la vez sustituir sum(scores) / scores.length por una función average disponible y eliminar esa misma función average por no estar usada, el resultado es una referencia a average que ya no existe. ESLint agrupa todas las correcciones compatibles en cuanto a rangos de edición, las aplica de golpe y vuelve a analizar; elm-review, en cambio, aplica una sola corrección por iteración y reanaliza el código después de cada cambio. Esa estrategia, más lenta, garantiza que cada arreglo tenga sentido en el estado actual del archivo y evita conflictos entre reglas. El problema puede aparecer con cualquier par de reglas que apliquen cambios significativos —eliminaciones, renombrados, movimientos de código— y se vuelve más relevante a medida que los linters adoptan autofixes más agresivos, como borrado de código muerto o refactorizaciones estructurales. Los linters que no admiten reglas personalizadas podrían mitigarlo con prioridades o resolviendo colisiones de antemano; quienes sí lo hacen, como ESLint o elm-review, afrontan el dilema entre velocidad y corrección. La solución del autor, aunque costosa en rendimiento, elimina por completo la preocupación de que los fixes de una regla entren en conflicto con los de otra.