What is oxlint and how to use it

ESLint runs on Node.js, interpreting JavaScript to analyze other JavaScript, and on a large codebase, lint time easily becomes the CI bottleneck. oxlint exists to solve exactly that problem: it’s a linter written in Rust, part of the Oxc project (Oxidation Compiler), shipped as a native binary — no JavaScript VM to spin up, no general-purpose garbage collector, real multi-threaded parallelism.

The number that matters: 50-100x

Benchmarks published by the Oxc team on real projects show oxlint finishing in a few seconds what takes ESLint minutes, with gains ranging from 50x to 100x depending on project size and the number of active rules. The difference isn’t marginal: on a large repository it can mean the gap between a lint check that blocks every commit and one that disappears into the background of the workflow.

How to configure it

npm init @oxlint

This generates an .oxlintrc.json file, with different syntax from .eslintrc but a similar underlying idea: rules grouped by category (correctness, suspicious, pedantic, style, perf) instead of by plugin.

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

Running it is a single command:

oxlint

No node_modules traversal to load plugins, no cascading config resolution — the binary reads the config file and goes.

What it actually covers (and what it doesn’t)

oxlint doesn’t run existing ESLint plugins: it natively reimplements, in Rust, a growing subset of the most-used ESLint core rules and popular plugins — eslint-plugin-react, eslint-plugin-jsx-a11y, eslint-plugin-unicorn, part of @typescript-eslint. That’s the real trade-off: if your project depends on a niche ESLint plugin, or a custom rule written in JavaScript, oxlint simply has no equivalent — there’s no JS-based plugin system like ESLint’s, because JavaScript-level extensibility would undercut the speed advantage of the Rust engine.

For type-aware linting (rules that need to know types, not just syntax — e.g. detecting a missing await on a Promise), oxlint relies on tsgo, the native Go-based TypeScript compiler that’s becoming the standard with TypeScript 7 (covered in the TypeScript 7 article). This kind of analysis stays slower than purely syntactic linting, but it’s still faster than the equivalent based on classic tsc.

The most common migration strategy

Very few projects drop ESLint entirely in one step. The common pattern is running both side by side: oxlint runs as a first, very fast pass on every save or pre-commit hook; ESLint stays around for the rules oxlint doesn’t cover yet. To avoid the same issue being flagged twice, there’s eslint-plugin-oxlint, which disables in ESLint every rule that oxlint is already enforcing.

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

export default [
  // ...your existing ESLint config
  ...oxlint.configs["flat/recommended"],
];

Is it worth adopting today?

If your project is standard JavaScript/TypeScript without exotic ESLint plugins, oxlint can probably replace ESLint almost entirely and give back precious seconds on every local lint run and in CI. If your setup depends on custom rules or niche plugins, the pragmatic path is running it alongside ESLint via eslint-plugin-oxlint: speed where possible, full coverage where needed.