Cos'è oxlint e come si usa

ESLint gira su Node.js, interpreta JavaScript per analizzare altro JavaScript, e su una codebase grande il tempo di lint diventa facilmente il collo di bottiglia della CI. oxlint nasce per risolvere esattamente questo problema: è un linter scritto in Rust, parte del progetto Oxc (Oxidation Compiler), distribuito come binario nativo — niente VM JavaScript da avviare, niente garbage collector generico, parallelismo reale su più thread.

Il numero che conta: 50-100x

I benchmark pubblicati dal team Oxc su progetti reali mostrano oxlint completare in pochi secondi quello che ESLint impiega minuti a fare, con guadagni che vanno dalle 50 alle 100 volte a seconda della dimensione del progetto e del numero di regole attive. La differenza non è marginale: su una repository grande può significare la differenza tra un check di lint che blocca ogni commit e uno che sparisce nel rumore di fondo del workflow.

Come si configura

npm init @oxlint

Genera un file .oxlintrc.json, con una sintassi diversa da .eslintrc ma concettualmente simile: regole raggruppate per categoria (correctness, suspicious, pedantic, style, perf) invece che per plugin.

{
  "categories": {
    "correctness": "error",
    "suspicious": "warn"
  },
  "rules": {
    "no-unused-vars": "error"
  }
}

L’esecuzione è un singolo comando:

oxlint

Nessun node_modules da attraversare per caricare plugin, nessuna configurazione a cascata da risolvere — il binario legge il file di config e via.

Cosa copre davvero (e cosa no)

oxlint non esegue i plugin ESLint esistenti: reimplementa nativamente in Rust un sottoinsieme crescente delle regole più usate di ESLint core e dei plugin più popolari — eslint-plugin-react, eslint-plugin-jsx-a11y, eslint-plugin-unicorn, una parte di @typescript-eslint. È qui il compromesso reale: se il tuo progetto dipende da un plugin ESLint di nicchia, o da una regola custom scritta in JavaScript, oxlint semplicemente non ha un equivalente — non c’è un sistema di plugin JS-based come in ESLint, perché l’estensibilità via JavaScript vanificherebbe il vantaggio di velocità del motore Rust.

Per il linting type-aware (regole che richiedono di conoscere i tipi, non solo la sintassi — es. rilevare un await mancante su una Promise), oxlint si appoggia a tsgo, il compilatore TypeScript nativo scritto in Go che sta diventando lo standard con TypeScript 7 (ne ho parlato nell’articolo su TypeScript 7). Questo tipo di analisi resta più lento del linting puramente sintattico, ma comunque più rapido dell’equivalente basato su tsc classico.

La strategia di migrazione più comune

Pochissimi progetti abbandonano ESLint del tutto in un colpo. Il pattern diffuso è farli convivere: oxlint gira come primo passaggio, velocissimo, su ogni salvataggio o pre-commit; ESLint resta per le regole che oxlint non copre ancora. Per evitare che le stesse regole vengano segnalate due volte, esiste eslint-plugin-oxlint, che disattiva in ESLint tutte le regole che oxlint sta già applicando.

// eslint.config.js
import oxlint from "eslint-plugin-oxlint";

export default [
  // ...la tua config ESLint esistente
  ...oxlint.configs["flat/recommended"],
];

Vale la pena adottarlo oggi?

Se il progetto è JavaScript/TypeScript standard, senza plugin ESLint esotici, oxlint può probabilmente sostituire ESLint quasi del tutto e restituire secondi preziosi a ogni lint locale e in CI. Se invece il tuo setup dipende da regole custom o plugin di nicchia, la via pragmatica è farlo convivere con ESLint via eslint-plugin-oxlint: velocità dove possibile, copertura completa dove serve.