OxLint: The Rust-Based JavaScript Linter That's 50-100x Faster Than ESLint

OxLint: The Rust-Based JavaScript Linter That's 50-100x Faster Than ESLint

ESLint has been the standard JavaScript linter for over a decade. It works. It has thousands of plugins. But it is also slow. On large codebases, ESLint can take 30 seconds or more to lint the entire project. That delay adds up across CI runs, editor saves, and pre-commit hooks. OxLint changes the equation entirely.

OxLint is a JavaScript and TypeScript linter written in Rust as part of the oxc (Oxidation Compiler) project. It reimplements the most commonly used ESLint rules natively, achieving 50-100x faster execution. On a project where ESLint takes 40 seconds, OxLint finishes in under a second. It is not a wrapper or a bridge -- it is a ground-up rewrite of linting logic in a systems language.

Why OxLint?

Raw speed: OxLint processes files in parallel using Rust's threading model. There is no Node.js startup cost, no plugin resolution overhead, and no AST serialization between JavaScript boundaries. The parser (oxc-parser) is one of the fastest JavaScript parsers ever built.

Zero configuration by default: OxLint works out of the box with no config file. It enables a curated set of correctness rules that catch real bugs -- not stylistic preferences. You can run oxlint . on any project and get useful results immediately.

ESLint compatibility: OxLint implements rules using the same names as their ESLint equivalents. If you use no-unused-vars in ESLint, OxLint's version behaves the same way. This makes migration straightforward.

Focused scope: OxLint deliberately focuses on linting. It does not try to be a formatter (use Prettier, Biome, or dprint for that). This focus lets it do one thing exceptionally well.

Installation

npm / Bun / pnpm

# npm
npm install -D oxlint

# Bun
bun add --dev oxlint

# pnpm
pnpm add -D oxlint

Standalone binary

# macOS / Linux
curl -sSfL https://oxc.rs/install.sh | sh

# Homebrew
brew install oxc

# Cargo
cargo install oxlint

Verify installation

oxlint --version

Basic Usage

Run OxLint on your project:

# Lint the current directory
oxlint .

# Lint specific directories
oxlint src/ lib/

# Lint specific file types
oxlint "src/**/*.ts" "src/**/*.tsx"

OxLint outputs diagnostics in a format similar to ESLint, with file paths, line numbers, and rule names. Errors are color-coded by severity.

Configuration

While OxLint works without configuration, you can customize it with an .oxlintrc.json file:

{
  "rules": {
    "no-unused-vars": "warn",
    "no-console": "off",
    "eqeqeq": "error",
    "no-debugger": "error"
  },
  "settings": {
    "jsx-a11y": {
      "polymorphicPropName": "as"
    }
  },
  "ignorePatterns": ["dist", "node_modules", "*.config.js"]
}

Rule categories

OxLint organizes rules into categories that you can enable or disable as a group:

# Enable all correctness rules (default)
oxlint -D correctness .

# Enable pedantic rules for stricter checking
oxlint -D pedantic .

# Enable nursery rules (experimental, may change)
oxlint -D nursery .

# Combine categories
oxlint -D correctness -D pedantic .

# Disable a specific rule
oxlint -D correctness -A no-unused-vars .

The -D flag denotes "deny" (enable as error), -W is "warn", and -A is "allow" (disable).

Plugin rules

OxLint includes built-in support for rules from popular ESLint plugins without requiring you to install those plugins:

• typescript-eslint: Rules for TypeScript-specific patterns
• eslint-plugin-react: React-specific linting rules
• eslint-plugin-react-hooks: Rules of Hooks enforcement
• eslint-plugin-jsx-a11y: Accessibility checks for JSX
• eslint-plugin-import: Import/export validation
• eslint-plugin-unicorn: Various helpful rules
• eslint-plugin-jest and eslint-plugin-vitest: Test-specific rules

Enable plugin rules with the --plugin flag or in configuration:

# Enable TypeScript rules
oxlint --plugin typescript .

# Enable React + accessibility rules
oxlint --plugin react --plugin jsx-a11y .

Migrating from ESLint

The migration path depends on your goals. You have two strategies:

Strategy 1: Run OxLint alongside ESLint

This is the low-risk approach. Add OxLint to catch bugs fast, keep ESLint for the rules OxLint does not yet cover.

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

OxLint runs first because it finishes in milliseconds. If it finds errors, you get feedback immediately without waiting for ESLint.

Strategy 2: Replace ESLint entirely

If the rules you rely on are all implemented in OxLint, you can drop ESLint:

1. Run oxlint . --format=json and compare output with eslint . --format=json
2. Identify any ESLint rules you depend on that OxLint does not implement
3. If the gap is acceptable, remove ESLint and its plugins from package.json
4. Replace your .eslintrc with .oxlintrc.json

Check the oxc rules reference for the current list of implemented rules.

Performance Benchmarks

Real-world performance comparisons on a mid-size TypeScript project (approximately 1,500 files, 200,000 lines of code):

These numbers vary by project size, rule count, and hardware, but the order of magnitude is consistent. OxLint is not slightly faster -- it operates in a fundamentally different performance tier.

The speed advantage is most impactful in three scenarios:

• CI pipelines: Linting drops from being one of the slowest CI steps to essentially free
• Pre-commit hooks: No more waiting several seconds before your commit goes through
• Editor feedback: Near-instant diagnostics as you type

IDE Integration

VS Code

Install the oxc extension from the VS Code marketplace. It provides real-time diagnostics, quick fixes, and integrates with the problems panel.

// settings.json
{
  "oxc.enable": true,
  "oxc.configPath": ".oxlintrc.json"
}

Neovim

Use the built-in LSP client with the oxc language server, or configure it through nvim-lspconfig:

require('lspconfig').oxc.setup({
  cmd = { "oxc_language_server" },
  filetypes = { "javascript", "typescript", "javascriptreact", "typescriptreact" },
})

JetBrains (IntelliJ, WebStorm)

The oxc plugin is available in the JetBrains Marketplace. Install it through Settings > Plugins and it will automatically detect your .oxlintrc.json.

CI Integration

Add OxLint to your CI pipeline for fast feedback:

# GitHub Actions
name: Lint
on: [push, pull_request]
jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: oxc-project/oxlint-action@v0
        with:
          args: --deny correctness --plugin typescript .

Since OxLint completes in under a second for most projects, you can run it as the first step in CI. Developers get lint feedback before slower steps like type checking or testing even begin.

When to Use OxLint vs. Other Tools

Use OxLint when: You want the fastest possible lint feedback, your rules are covered by OxLint's implementation, or you want to add a fast lint pass alongside your existing setup.

Stay with ESLint when: You depend on custom ESLint plugins that OxLint does not yet implement, or you need rules for ecosystems OxLint does not cover (Vue, Angular, Svelte-specific rules).

Consider Biome when: You want a single tool for both linting and formatting. Biome covers both, while OxLint focuses solely on linting.

Practical Tips

• Start with the default rule set. OxLint's defaults are carefully chosen to catch real bugs without noise.
• Use oxlint --fix . to auto-fix issues where safe fixes are available.
• Run oxlint --rules to see every available rule and its current status.
• Pin the OxLint version in CI to avoid unexpected rule changes between releases.
• Use the --threads flag to control parallelism if you need to limit CPU usage in shared CI environments.

OxLint represents a shift in what developers should expect from their tooling. Linting an entire codebase in under a second is not a gimmick -- it changes how you interact with your linter. Instead of running it occasionally or only in CI, you run it constantly, on every save, on every commit, with zero friction.