Oxlint

Oxlint is the linter of the Oxc (Oxidation Compiler) project, a suite of Rust-based JavaScript and TypeScript tooling built by the team behind Rolldown and the VoidZero unified toolchain. It parses and analyzes source files with the same high-performance Rust engine that powers Oxc’s parser and semantic analyzer, running lint passes across an entire codebase in milliseconds using Rayon-based multi-threading — commonly reported as 50-100x faster than ESLint on equivalent workloads.

With over 900 built-in rules spanning ESLint core, TypeScript, React, Next.js, Jest/Vitest, Unicorn, JSX-a11y, and other popular plugin ecosystems, oxlint works out of the box with zero configuration while also supporting .oxlintrc.json config files, ESLint-compatible rule severities, an --init command, automated migration tooling from existing ESLint setups, a built-in language server for editor integration, and — via the optional oxlint-tsgolint companion — type-aware linting rules that would otherwise require the full TypeScript compiler.

What You Get

• 900+ built-in lint rules covering ESLint core, TypeScript, React, Next.js, JSX-a11y, Jest/Vitest, Unicorn, Promise, and more, enabled through plugin categories rather than individual installs
• A Rayon-parallelized Rust linting engine that reuses Oxc’s shared parser/AST/semantic-analysis layer, delivering order-of-magnitude speedups over JS-based linters
• Zero-config operation for the common case, plus .oxlintrc.json for ESLint-style plugin selection, overrides, ignore patterns, globals, and per-rule severities
• An oxlint --init migration path and automated ESLint-config translation tooling to move an existing ESLint setup over incrementally
• A built-in language server (--lsp) for real-time diagnostics in editors, and JSON/GitHub Actions/checkstyle/SARIF-style output formatters for CI

Common Use Cases

• Replacing or front-loading ESLint in CI to catch the majority of lint violations in milliseconds before a slower, type-aware pass runs
• Linting large monorepos where ESLint’s Node.js-based rule execution becomes a bottleneck as file counts grow
• Adding fast pre-commit/pre-push lint checks without paying ESLint’s startup and rule-execution overhead on every run
• Migrating an existing ESLint configuration incrementally via automated config translation and rule-compatibility mapping

Under The Hood

Architecture - Oxlint is the CLI crate (apps/oxlint, entry point src/main.rs) built on top of the oxc_linter library crate. The CLI parses arguments with bpaf, then hands off to CliRunner, which drives LintService (crates/oxc_linter/src/service/mod.rs) — a Rayon-parallelized file-walking runtime that reuses Oxc’s shared oxc_allocator/oxc_parser/oxc_semantic pipeline to parse and semantically analyze each file once, then runs every applicable RuleEnum against the resulting AST/semantic graph. Rules are looked up through a ConfigStore built from .oxlintrc.json (crates/oxc_linter/src/config/), and diagnostics flow through oxc_diagnostics/miette for terminal rendering or through pluggable output formatters for CI. A separate --lsp mode spins up a Tokio runtime and language server (src/lsp/) for editor integration, while the napi/ crate exposes the same lint_impl entry point to the oxlint npm package via NAPI-RS, including hooks (JsLoadPluginCb, JsLintFileCb, etc.) for loading JS-authored plugins and type-aware tsgolint rules.

Tech Stack - Rust (workspace Cargo.toml, 100+ member crates under crates/*, apps/*, napi/*), with rayon for data-parallel linting, bpaf for CLI argument parsing, oxc-miette for diagnostic rendering, tracing/tracing-subscriber for structured logging, napi/napi-derive (NAPI-RS) for the Node.js binding published as the oxlint package with per-platform prebuilt binaries (napi targets cover 19 OS/arch combinations), and tokio scoped narrowly to the LSP path so the default synchronous CLI lint run avoids spawning idle async worker threads.

Code Quality - The oxc_linter crate is organized into clearly separated modules (config, context, fixer, service, suppression, rules), each of the 900+ rules lives in its own file under crates/oxc_linter/src/rules/, and 772 of those rule files contain inline #[test] fn test() unit tests exercising pass/fail cases — a strong majority of the ruleset. The crate also carries workspace-wide Clippy lints ([lints] workspace = true) with targeted, commented #[expect(...)] overrides rather than blanket allows, and a size_asserts test pins RuleEnum to 16 bytes to guard a documented 15% performance win from a past size reduction, showing performance-sensitive code paths are actively monitored.

API Design - The Rule trait (crates/oxc_linter/src/rule.rs) gives rule authors a small, well-documented surface — run, run_once, run_on_jest_node, should_run, from_configuration — each with sensible no-op defaults and doc comments explaining when to implement them, so a new rule can start from a handful of methods without touching the linting engine itself. For end users, the CLI is designed to work with zero flags (npx oxlint@latest) and documents its options through --help, --rules, and an --init scaffolding command, while .oxlintrc.json mirrors ESLint’s configuration shape to minimize the conceptual overhead of switching linters.