Why is Oxlint better than ESLint?

Speed changes what you can afford to lint. Airbnb runs import/no-cycle across more than 126,000 files in 7 seconds on CI with Oxlint, where ESLint's version of the rule times out, and Mercedes-Benz reported a 71% drop in lint time. It has 872 built-in rules covering ESLint core, typescript-eslint, React, Jest, Vitest, import, unicorn and jsx-a11y, so most configs need no plugin packages. Type-aware rules run on typescript-go, the native TypeScript 7 compiler, and cover 59 of the 61 type-aware rules in typescript-eslint. @oxlint/migrate converts an ESLint v9 or v10 flat config, keeping severities, rule options, per-path overrides and ignore patterns. Its default rules target code that is incorrect, unsafe or useless, so it is useful with no configuration at all.

Instead of ESLint: Oxlint

Use Oxlint. It runs most ESLint core and plugin rules natively in Rust, the Oxc team measures it at 50 to 100 times faster than ESLint, and a migration tool converts an ESLint flat config for you. Keep ESLint next to it only for the rules and plugins Oxlint cannot run yet.

Old ESLint ★ 28k MIT JavaScript Pushed today eslint.org

Instead Oxlint ★ 23k MIT Rust Pushed today oxc.rs

Both are for linting JavaScript and TypeScript code for bugs and bad patterns.

Why Oxlint is better

Speed changes what you can afford to lint. Airbnb runs import/no-cycle across more than 126,000 files in 7 seconds on CI with Oxlint, where ESLint's version of the rule times out, and Mercedes-Benz reported a 71% drop in lint time.
It has 872 built-in rules covering ESLint core, typescript-eslint, React, Jest, Vitest, import, unicorn and jsx-a11y, so most configs need no plugin packages.
Type-aware rules run on typescript-go, the native TypeScript 7 compiler, and cover 59 of the 61 type-aware rules in typescript-eslint.
@oxlint/migrate converts an ESLint v9 or v10 flat config, keeping severities, rule options, per-path overrides and ignore patterns.
Its default rules target code that is incorrect, unsafe or useless, so it is useful with no configuration at all.

When to keep ESLint

Keep ESLint when you depend on a rule or plugin Oxlint does not cover and that does not run under its JS plugin support, or when a framework integration assumes ESLint. ESLint is still the default by a wide margin, with 9,697 State of JS 2025 respondents named it, against 123 for Oxlint.

Switching

Run npx @oxlint/migrate to turn eslint.config.js into .oxlintrc.json, then run oxlint in CI. For large repos the Oxc docs suggest running both for a while, oxlint first and then ESLint with the overlapping rules switched off by eslint-plugin-oxlint, and dropping ESLint once nothing depends on it.

Watch out

Support for ESLint JS plugins is still alpha. Type-aware linting needs an extra package, oxlint-tsgolint. Minor releases add rules, which can fail a CI run on code that passed before, so pin the version. Oxlint comes from the Oxc project at VoidZero, the company that also builds Rolldown for Vite.

Also worth a look

Biome A Rust linter and formatter in one tool with 755 rules; pick it if you also want to replace Prettier with the same binary and config file.

More newer, better linters, formatters and type checkers

Sources

Judged on 2026-11-06. See every linters, formatters and type checkers, or all 66 replacements.