# Cos'è oxlint e come si usa

> oxlint è un linter per JavaScript e TypeScript scritto in Rust, 50-100x più veloce di ESLint. Come si configura, cosa copre davvero e perché non lo sostituisce del tutto.

- Autore / Author: Diego Betto (https://diegobetto.com/about/)
- Pubblicato / Published: 2026-10-15
- URL: https://diegobetto.com/oxlint-linter-guida/
- Tag: javascript, typescript, tools

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

```bash
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.

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

L'esecuzione è un singolo comando:

```bash
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](https://diegobetto.com/typescript-7-novita/)). 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.

```js
// 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.