Oxlint – linter de JavaScript escrito en Rust
Un nuevo linter de JavaScript escrito en Rust, Oxlint, está llamando la atención por ser decenas a miles de veces más rápido que ESLint en bases de código grandes, especialmente en canalizaciones de CI. Los comentaristas agradecen el rendimiento y la historia de dependencias más simple, pero señalan importantes concesiones: cobertura limitada de reglas, falta de un ecosistema maduro de plugins y reglas personalizadas, y el riesgo de fragmentar las herramientas entre múltiples reemplazos basados en Rust como Biome y Bun. El debate refleja una tendencia más amplia a reescribir herramientas de JS en lenguajes compilados, equilibrando velocidad bruta y simplicidad frente a configurabilidad, extensibilidad y mantenibilidad a largo plazo.
Impacto en el rendimiento y en CI
- A muchos les impresionan las supuestas aceleraciones de 50–100x frente a ESLint; un caso: 75 minutos en más de 40 trabajadores de CI → ~10 segundos en un solo trabajador.
- Algunos sostienen que esto es transformador para monorepos grandes y para el linting de todo el repositorio en CI; otros dicen que el lint rara vez es el cuello de botella y prefieren linting parcial (solo archivos modificados) o enfoques incrementales.
- Debate sobre si el linting de todo el repositorio es necesario; las reglas conscientes de tipos y entre archivos se citan como razones por las que el linting parcial es difícil.
Reglas, personalización y compatibilidad con el ecosistema
- Un gran obstáculo para la adopción: la falta de paridad con las ~cientos de reglas de ESLint y su rico ecosistema de plugins (TypeScript, React, reglas de importación, “rules of hooks”, etc.).
- Varios dependen mucho de reglas personalizadas de ESLint como “codemods continuos” y análisis estático específico del proyecto, por lo que ven ESLint como irremplazable hasta que existan equivalentes.
- El soporte planificado de Oxlint para reglas personalizadas mediante consultas de Trustfall y YAML se ve como prometedor, pero aún está en una fase temprana.
DX, configuración y flujo de trabajo
- La configuración de ESLint se describe ampliamente como compleja y frágil, especialmente con TypeScript/React y varios conjuntos de reglas superpuestos.
- Algunos elogian herramientas que “simplemente funcionan” con una configuración mínima (Ruff para Python, el linter/formateador integrado de Deno, las convenciones de Go/Rust) y desean algo similar en JS/TS.
- Otros sostienen que la configuración inicial del lint es un coste de una sola vez y que las configuraciones estables pueden durar años.
Comparaciones con otras herramientas
- Comparaciones frecuentes con Ruff (Python), Biome (ex‑Rome), Bun, Deno, dprint, Pyright, mypy, TypeScript en sí.
- Surge la pregunta de por qué elegir oxlint en lugar de Biome; una respuesta: un enfoque más fuerte en la compatibilidad con ESLint, aunque Biome supuestamente implementa más reglas de ESLint hoy.
Reescrituras en Rust y elección del lenguaje
- El hilo sitúa a oxlint dentro de una tendencia más amplia de reescribir herramientas de JS en lenguajes compilados (Rust, Go, Zig).
- Los partidarios: enormes mejoras de velocidad, mejor disposición de memoria para ASTs, buena distribución mediante binarios únicos, Rust más accesible que C/C++.
- Los críticos: los problemas de rendimiento pueden ocultar problemas más profundos de complejidad/deuda técnica; usar algo que no sea JS para herramientas de JS puede reducir el grupo de colaboradores y poner en riesgo la sostenibilidad a largo plazo.
Filosofía del linting
- Desacuerdo sobre si el linting debe ser ligero y solo de estilo o un análisis estático profundo, central en el desarrollo.
- Algunos ven el linting pesado como una extralimitación y una carga de mantenimiento; otros consideran que un análisis estático fuerte y específico del proyecto es un gran “superpoder” de productividad y calidad.