Oxlint vs ESLint: Rust Linting Performance 2026

Oxlint is 50-100x faster than ESLint. On a 264,000-file codebase, Oxlint processes ~10,000 files per second. Mercedes-Benz saw a 71% decrease in lint time after switching. Shopify uses Oxlint in production. Yet ESLint still has 68 million weekly npm downloads to Oxlint's 638K. The performance advantage is real — the ecosystem gap is also real.

TL;DR

Oxlint is the fastest JavaScript linter available in 2026, and it's ready for production use. The smart migration path is running Oxlint alongside ESLint — Oxlint handles the fast foundational rules, ESLint handles plugins Oxlint can't replace. Full migration makes sense for new projects or projects without ESLint plugin dependencies.

Key Takeaways

• Oxlint: 50-100x faster than ESLint per official benchmarks
• ESLint: 68M weekly downloads; Oxlint: 638K weekly downloads (growing fast)
• Oxlint v1.0 went stable in August 2025 (backed by VoidZero, the team behind Vite/Rolldown)
• Oxlint has 695 built-in rules; ESLint's ecosystem has tens of thousands via plugins
• eslint-plugin-oxlint lets you disable ESLint rules covered by Oxlint (run both tools)
• Companies using Oxlint in production: Shopify, Mercedes-Benz, Airbnb, Zalando

What Is Oxlint?

Oxlint is a JavaScript/TypeScript linter written in Rust, part of the OXC (Oxidation Compiler) project. OXC is building a complete JavaScript toolchain in Rust — Oxlint is the first production-ready piece.

npm install -D oxlint
# or
npx oxlint . --deny-warnings

Unlike ESLint, Oxlint is a single binary. No configuration required to start getting value.

Speed Comparison

Raw Benchmarks (264,925 files)

Tool	Time	Files/sec
Oxlint	22.5s	11,774
ESLint (no type-checking)	~35 min	~125
Biome	~45s	~5,887

Oxlint benchmarks show it processing files approximately 62x faster than ESLint in real-world testing.

Why So Fast?

1. Rust: No JavaScript VM overhead, no garbage collection pauses
2. Parallelism: Uses all CPU cores by default (ESLint is single-threaded)
3. Architecture: Unified parser with minimal allocations, no plugin overhead
4. No plugin system (yet): Plugin loading and initialization adds significant overhead to ESLint

Installation and Basic Usage

npm install -D oxlint

# Lint current directory
npx oxlint .

# Lint with all recommended rules
npx oxlint . --rules-of-hooks

# Fix auto-fixable issues
npx oxlint . --fix

# JSON output
npx oxlint . --format json

Configuration (oxlint.json)

{
  "$schema": "https://raw.githubusercontent.com/oxc-project/oxc/main/crates/oxc_linter/schemas/oxlintrc.schema.json",
  "plugins": ["react", "unicorn", "import"],
  "env": {
    "browser": true,
    "node": true
  },
  "rules": {
    "no-unused-vars": "error",
    "no-console": "warn",
    "prefer-const": "error",
    "eqeqeq": ["error", "always"],
    "react/rules-of-hooks": "error",
    "react/jsx-no-target-blank": "error"
  },
  "overrides": [
    {
      "files": ["*.test.ts"],
      "rules": {
        "no-console": "off"
      }
    }
  ]
}

Rule Coverage (695 Rules)

Oxlint v1.x includes rules in these categories:

Category	Count	Examples
Correctness	200+	no-unused-vars, no-undef, array-type
Suspicious	100+	no-debugger, no-eval, typeof-comparison
Style	150+	prefer-const, no-var, arrow-function
React	80+	rules-of-hooks, jsx-no-target-blank
TypeScript	100+	no-explicit-any, consistent-type-imports
Unicorn	50+	filename-case, no-process-exit
Import	50+	no-duplicates, no-cycle

React Plugin

{
  "plugins": ["react"],
  "rules": {
    "react/rules-of-hooks": "error",
    "react/exhaustive-deps": "warn",
    "react/jsx-no-target-blank": "error",
    "react/no-direct-mutation-state": "error"
  }
}

Oxlint's React plugin covers the most important eslint-plugin-react-hooks rules.

The Recommended Migration: Run Both

The most pragmatic 2026 approach is running Oxlint for fast foundational checks and ESLint for plugin-specific rules you can't yet replace:

npm install -D oxlint eslint-plugin-oxlint

// eslint.config.js — disable rules Oxlint already covers
import oxlint from 'eslint-plugin-oxlint';

export default [
  // Your ESLint config for plugin-specific rules...
  js.configs.recommended,
  ...ts.configs.recommended,
  {
    plugins: { react, 'react-hooks': reactHooks },
    rules: {
      // Accessibility rules Oxlint doesn't have
      'jsx-a11y/alt-text': 'error',
      'jsx-a11y/anchor-is-valid': 'error',
    },
  },
  // Disable ESLint rules that Oxlint handles (avoid duplication)
  oxlint.configs['flat/recommended'],
];

// package.json scripts
{
  "scripts": {
    "lint": "oxlint . && eslint .",
    "lint:fast": "oxlint ."
  }
}

With this setup:

• lint:fast: Oxlint only (use in pre-commit, CI fast path)
• lint: Full lint with both tools (use for thorough checks)

The ESLint run is now much faster because eslint-plugin-oxlint disables rules Oxlint already handles.

Pre-commit Hook Optimization

// .lintstagedrc
{
  "*.{js,jsx,ts,tsx}": [
    "oxlint --fix",     // Fast: ~200ms for 50 files
    "eslint --fix --rule 'jsx-a11y/*: error'"  // Only accessibility rules
  ]
}

Type-Aware Linting

Oxlint added type-aware linting support (via TypeScript's type checker) in v0.15+:

{
  "typescript": {
    "tsconfig": "./tsconfig.json"
  },
  "rules": {
    "no-unsafe-assignment": "error",
    "no-unsafe-call": "error",
    "no-unsafe-return": "error"
  }
}

Type-aware linting is 12x faster than ESLint's typescript-eslint equivalent (still uses TypeScript's type checker but with better parallelism).

What Oxlint Can't Replace Yet

ESLint Plugin	Oxlint Support	Notes
eslint-plugin-react-hooks	Partial	hooks rules covered, not all rules
eslint-plugin-jsx-a11y	Partial	basic a11y, not comprehensive
eslint-config-next	No	Next.js-specific rules
eslint-plugin-storybook	No	Not yet
@angular-eslint	No	Not yet
Custom rules	No	No plugin API yet

The plugin API is the biggest gap. Oxlint v2 (planned) includes a plugin system, which will enable community-built plugins.

Production Adoption

Shopify

Shopify added Oxlint to their admin codebase (one of the largest React applications). They run Oxlint as a fast pre-commit check and ESLint in CI.

Mercedes-Benz

Reported 71% reduction in lint time after switching. Their codebase had ~80K TypeScript files.

Airbnb

Using Oxlint for their internal TypeScript codebase alongside ESLint.

ESLint's Response

ESLint isn't standing still. The ESLint team has started a "rewrite" project to improve performance:

• ESLint v9+ with flat config is measurably faster than v8
• TypeScript ESLint v8 (2025) includes performance improvements
• A planned Rust-based ESLint is in early research

However, even optimized ESLint is unlikely to close the 50-100x gap with Oxlint.

When to Use Oxlint

Use Oxlint as primary linter if:

• Starting a new JavaScript/TypeScript project
• Your codebase doesn't rely on ESLint plugins Oxlint doesn't cover
• Pre-commit or CI lint time is a significant bottleneck
• You're working in a plain TypeScript/Node.js project without heavy framework plugins

Use Oxlint alongside ESLint if:

• You need eslint-plugin-jsx-a11y for accessibility
• eslint-config-next is required for Next.js
• Custom ESLint rules are in use
• You want fast feedback without losing plugin coverage

Stick with ESLint only if:

• You have complex custom ESLint plugins that Oxlint can't replace
• Your team is ESLint experts and migration friction isn't worth the speed gain
• You're using framework-specific tooling that bundles ESLint

npm Package Comparison

Package	Weekly Downloads	GitHub Stars
eslint	68M	26K
oxlint	638K	17K
@biomejs/biome	500K	20K

Oxlint's growth trajectory is steep. At current rates, it'll cross 2M weekly downloads before end of 2026.

Ecosystem & Community

The OXC project (which includes Oxlint) is backed by VoidZero — the company that Evan You (Vue.js creator) founded to build the next generation of JavaScript tooling. This institutional backing distinguishes OXC from hobby projects and gives it a clear roadmap and commercial sustainability. The OXC Discord is active with daily discussion about new rules, bug reports, and integration questions.

Oxlint's rule additions are faster than ESLint's. Because the OXC team controls the parser, adding a new lint rule doesn't require working around parser edge cases — a common bottleneck in ESLint plugin development. When a rule is requested on the Oxlint GitHub, it typically ships within one to three releases.

The ESLint ecosystem remains the reference point. With hundreds of community plugins and years of rules covering every possible code style, it's unlikely that Oxlint closes this gap in 2026. However, for the 80% of rules that most teams actually enable, Oxlint's coverage is already sufficient.

Developer Experience Deep Dive

Oxlint's error output is clean and actionable. Each violation includes the rule name, a clear description, and the affected code snippet. The --fix flag handles the same auto-fixable categories as ESLint's --fix. The JSON output format is compatible with tools that consume ESLint JSON output, making it easy to integrate with CI dashboards and IDE plugins.

VS Code integration for Oxlint is available through the official Oxlint extension. It provides real-time linting feedback as you type, which is where the speed advantage is most apparent — Oxlint's re-lint on save is imperceptible, while ESLint on a large TypeScript project can add 500-1000ms of latency to the save-to-feedback cycle.

The IDE experience for ESLint remains broader. The ESLint VS Code extension has years of polish, edge case handling, and configuration UI. Teams that rely heavily on ESLint's IDE integration may find the Oxlint extension is slightly less mature. This gap is closing rapidly.

Migration Guide

Migrating from ESLint-only to an Oxlint-first setup is a two-phase process. Phase one involves installing Oxlint, running it against your codebase, and fixing any violations it finds. On a typical TypeScript React project, Oxlint finds 200-500 fixable issues that ESLint was already catching — run oxlint --fix to resolve them automatically.

Phase two involves configuring eslint-plugin-oxlint to disable the ESLint rules that Oxlint now handles. This requires audit of your ESLint config to identify which rules overlap. The eslint-plugin-oxlint package automates most of this — installing and extending oxlint.configs['flat/recommended'] in your eslint.config.js disables the overlapping rules. After this step, your eslint . run covers only the plugin-specific rules that Oxlint can't handle, making it significantly faster.

Common pitfalls: some teams discover that their ESLint config was duplicating rules across multiple plugins. Consolidating these while migrating to Oxlint is a good opportunity to simplify. The other common issue is rules that Oxlint implements slightly differently than ESLint — the behavior is usually correct but the error message format or fixable status may differ.

Final Verdict 2026

Oxlint is not a complete ESLint replacement in 2026 — the plugin ecosystem gap is real and significant for teams using accessibility plugins, Next.js configs, or custom rules. But framing it as a replacement misses the point. The right mental model is: Oxlint is a fast correctness checker that runs in 200ms, while ESLint is a comprehensive style enforcement tool that runs in 30 seconds. Using both together gives you the best of both worlds.

For teams suffering from slow CI lint steps or pre-commit hooks that interrupt flow, Oxlint is an immediate, low-risk improvement. The eslint-plugin-oxlint integration makes it additive rather than disruptive. For new projects without existing ESLint investment, Oxlint as the primary linter with ESLint for accessibility is the recommended 2026 setup.

ESLint Flat Config Context

ESLint v9's flat config system (the new default since v9.0.0) is worth understanding in the context of an Oxlint migration. Flat config uses eslint.config.js instead of .eslintrc.* and changes how plugins and extends are specified. Teams migrating to Oxlint at the same time as upgrading to ESLint v9 flat config are doing two things at once, which can complicate debugging.

The recommendation is to migrate to ESLint flat config first if you haven't already — it's a mechanical process well documented by the ESLint team. Then add Oxlint and eslint-plugin-oxlint as a second step. This separation makes it easier to attribute any rule behavior changes to the right tool.

Flat config also makes it easier to apply different lint configurations to different directories. In a monorepo, you might enable stricter Oxlint rules in application code while relaxing them in test files, all in a single eslint.config.js. The programmatic nature of flat config (it's a JavaScript array, not YAML) means you can derive Oxlint overrides from the same data structures as your ESLint overrides.

Performance in CI: Real Workflow Impact

The most compelling case for adding Oxlint to an existing ESLint setup is the CI fast path story. Many teams configure CI with multiple lint checks: a fast correctness check that runs on every commit, and a thorough check that runs on PRs before merge. Oxlint is ideal for the fast correctness check because it runs in under 5 seconds on most codebases.

A concrete workflow: on every push, run oxlint . (2-5 seconds) and fail fast on correctness issues. On PR creation, run the full oxlint . && eslint . suite (20-40 seconds depending on codebase size). Developers get immediate feedback on the most critical issues without waiting for the full lint suite, while maintaining complete rule coverage before code merges.

Pre-commit hooks benefit similarly. Lint-staged with Oxlint runs in 200-500ms for a typical commit of 5-15 changed files. Adding ESLint for accessibility rules adds 1-3 seconds. The combined pre-commit hook stays under 5 seconds — below the threshold where developers start bypassing hooks. ESLint-only pre-commit hooks on large codebases can take 15-30 seconds, which reliably leads to developers adding --no-verify to their commit commands.

Compare on PkgPulse

Track download trends for ESLint vs Oxlint on PkgPulse.

Compare oxlint and ESLint package health on PkgPulse.

For related JavaScript tooling comparisons, see best monorepo tools 2026 for organizing lint configurations across packages.

For package management decisions that pair with your lint setup, see best JavaScript package managers 2026.

If you're evaluating the full OXC toolchain, Rolldown (OXC's bundler) is covered in the Rolldown vs esbuild Rust bundler comparison.