oxlint y oxfmt: linter y formateador a velocidad de Rust

Dentro de la familia Oxc hay dos piezas que puedes usar hoy, sin reescribir tu proyecto ni esperar a Vite 8: oxlint, el linter, y oxfmt, el formateador. La cifra que las define impresiona: oxlint es entre 50 y 100 veces más rápido que ESLint, y oxfmt unas 30 veces más rápido que Prettier. Pero lo verdaderamente interesante no es el número, sino de dónde sale y por qué te permite migrar sin fricción. Esta lección disecciona ambas herramientas y la estrategia de adopción que las hace irresistibles.

oxlint: el linter que cabe en un guardado

Un linter analiza tu código en busca de errores probables y malas prácticas: variables sin usar, promesas sin await, comparaciones sospechosas, dependencias mal declaradas en un hook. ESLint hace ese trabajo desde hace más de una década y es una pieza magnífica, pero su coste creció con los proyectos: en un monorepo grande, una pasada completa puede llevar minutos, y por eso se relega a la integración continua en vez de correr en cada guardado.

oxlint cambia la ecuación. Trae cientos de reglas integradas —muchas portadas desde los plugins más populares de ESLint—, arranca sin configuración y recorre bases de código enormes en segundos. Es tan rápido que deja de tener sentido reservarlo para el CI: puedes ejecutarlo en cada guardado, en un hook de pre-commit o al vuelo mientras editas, sin notar la espera.

# oxlint corre sobre tu codigo tal cual, sin configurar nada
npx oxlint@latest

# o acotado a una carpeta, con correcciones automaticas donde las haya
npx oxlint@latest src --fix

Por defecto se centra en reglas de correctitud —las que cazan bugs reales, no las meramente estilísticas— para que su salida sea señal y no ruido. Esa elección no es casual: un linter que tarda segundos y solo grita cuando importa se convierte en un compañero constante, mientras que uno lento y ruidoso acaba silenciado. Lo que ESLint te da en minutos, oxlint te lo da antes de que sueltes la tecla.

Sus reglas se agrupan en categorías reconocibles para quien viene de ESLint: correctness para los bugs casi seguros, suspicious para los patrones dudosos, y pedantic o style para el resto. Muchas provienen de los plugins más usados del ecosistema —el de React, el de TypeScript, el de importaciones—, reimplementadas sobre el AST de Oxc. Ajustarlas se hace con un archivo de configuración opcional, pero el valor está en que, sin tocar nada, ya cubre el grueso de lo que de verdad rompe un proyecto. Algunos ejemplos de lo que caza sin que se lo pidas:

• Variables e imports declarados y nunca usados.
• Promesas sin await y efectos con dependencias mal listadas.
• Comparaciones con == donde casi seguro querías ===.
• Claves duplicadas en un objeto o ramas inalcanzables en un switch.
• Uso de let donde nunca se reasigna el valor, o de var en código moderno.
• Igualdad laxa y conversiones implícitas que suelen esconder un error.

oxfmt: formatear deja de tener coste

oxfmt es el formateador de la familia, y su gran acierto es una decisión de compatibilidad: produce una salida compatible con el estilo de Prettier. Eso significa que adoptarlo no reescribe todo tu proyecto con otro formato ni genera un diff gigantesco que sepulte los cambios reales. El código queda prácticamente igual que con Prettier, pero formatearlo cuesta una fracción del tiempo: unas 30 veces menos.

# oxfmt formatea con un estilo compatible con Prettier, a velocidad de Rust
npx oxfmt@latest

# comprobar sin escribir, ideal para el CI
npx oxfmt@latest --check

La compatibilidad de estilo es una renuncia deliberada y astuta: oxfmt podría haber impuesto sus propias opiniones sobre comas o saltos de línea, pero eso habría convertido cada adopción en una guerra de diffs. Al imitar a Prettier, elimina el único motivo real para no probarlo. Y, como oxlint, su velocidad lo vuelve invisible: formatear al guardar deja de ser una micro-pausa perceptible y pasa a ser instantáneo.

Hay una razón más honda para que el formateo sea opinado y no configurable hasta el último detalle, y oxfmt la hereda de Prettier: un formateador sin apenas opciones elimina las discusiones de estilo del equipo. Si nadie puede ajustar la coma final ni la anchura de línea, nadie discute sobre ellas, y el formato deja de ser un tema en las revisiones. oxfmt conserva esa filosofía y le añade la velocidad que faltaba.

En la práctica, esto significa que puedes borrar el formateo de tu lista de tareas: se vuelve un efecto automático del guardado, tan invisible como fiable, y las revisiones dejan de gastarse en comas y sangrías para centrarse en lo que de verdad importa.

De dónde sale la velocidad

Las dos cifras —50 a 100 veces, 30 veces— no salen de trucos, sino de la misma raíz que viste con Oxc. ESLint y Prettier son programas en JavaScript, de un solo hilo, que parsean tu código con su propio parser antes de trabajar. oxlint y oxfmt están escritos en Rust, reparten el trabajo entre todos los núcleos de tu máquina y, sobre todo, reutilizan el AST de Oxc: parsean una vez con el parser más rápido del ecosistema y aplican las reglas o el formateo sobre ese árbol, sin releer el texto.

flowchart LR
subgraph ESLint_y_Prettier
  e1[JavaScript en un solo hilo] --> e2[Reparsea con su propio parser]
  e2 --> e3[Minutos en un monorepo]
end
subgraph oxlint_y_oxfmt
  o1[Rust y multihilo] --> o2[Reutiliza el AST de Oxc]
  o2 --> o3[Segundos en el mismo monorepo]
end
style e3 fill:#f38ba8,color:#11111b
style o3 fill:#a6e3a1,color:#11111b

Multiplica esos tres factores —lenguaje nativo, paralelismo real y una sola pasada de parseo— y el orden de magnitud deja de sorprender: es la consecuencia aritmética de no repetir trabajo y no pagar el peaje de la interpretación. No hay una regla secreta que oxlint aplique más rápido; simplemente no desperdicia el tiempo que sus predecesores gastaban en reparsear en un solo hilo.

Desglosado, el salto viene de tres multiplicadores que se acumulan:

• Lenguaje nativo: Rust compilado, sin el peaje de interpretar JavaScript con JavaScript.
• Paralelismo real: el trabajo se reparte entre todos los núcleos, no se encola en un hilo.
• Una sola pasada: se parsea una vez con el parser de Oxc y se reutiliza el árbol.

Ninguno de los tres es un truco; los tres juntos explican el factor de 50 a 100. Y como el mismo árbol alimenta al formateador, oxfmt disfruta de la misma aritmética: por eso ambas cifras, la del linter y la del formateador, tienen exactamente el mismo origen.

Migrar sin fricción

La velocidad abre la puerta, pero lo que hace irresistible a este par es la ausencia de fricción para adoptarlos. oxlint corre sobre tu código actual sin configurar nada: puedes incorporarlo hoy como un primer filtro rapidísimo en el pre-commit o en el CI, y mantener ESLint para las reglas que oxlint todavía no cubre —el análisis que depende de tipos y los plugins personalizados—. Ambos conviven, y a medida que el catálogo de reglas de oxlint crece, el papel de ESLint se encoge.

oxfmt juega la misma carta desde el lado del formato: como su salida es compatible con Prettier, cambiar de uno a otro no provoca la avalancha de cambios que temerías. La adopción es incremental y reversible; no hay que apostar todo de golpe. Un camino de migración sensato en 2026 se parece a esto:

• Semana uno: añade oxlint como primer paso del pre-commit, delante de ESLint. Coste cero, ganancia inmediata de latencia.
• Semana dos: activa oxfmt --check en el CI junto a Prettier y comprueba que el diff es mínimo.
• Después: ve trasladando reglas de ESLint a oxlint según las vaya cubriendo, y reduce la superficie de las herramientas lentas.

La clave de que este camino funcione es que cada paso es reversible y no bloquea a los demás: si oxlint marca un falso positivo, lo silencias y sigues; si oxfmt te incomoda en un archivo, vuelves a Prettier para ese caso. Nada de esto exige una decisión irreversible ni una reescritura de fin de semana, que es justo lo que hace que un equipo se atreva a empezar.

# Estrategia sin friccion: oxlint como filtro rapido en pre-commit
# y ESLint solo para las reglas type-aware que aun no cubre
npx oxlint@latest && npx eslint . --rulesdir ./reglas-type-aware

En un proyecto real, esto se cablea en los scripts para que nadie tenga que recordarlo:

// package.json: oxlint y oxfmt como primera linea, rapida
{
  "scripts": {
    "lint": "oxlint",
    "format": "oxfmt",
    "check": "oxlint && oxfmt --check"
  }
}