Add Oxc’s linter, oxlint, to your lint step today. Upgrade to Vite 8 and you get Rolldown for free. Hold off on the minifier. That’s the verdict — the rest of this article shows the numbers behind it.

Who this is for

Frontend and full-stack engineers who run ESLint on large codebases and feel the slowness, or who are on Vite 7 and considering an upgrade. If you’re on Next.js using Turbopack or on a Webpack stack with no Vite in sight, most of this doesn’t apply yet.

What we tested

Oxlint v1.x (v1 GA: June 2025; beta: March 2025). Oxlint JS plugins alpha (March 2026). Rolldown as shipped in Vite 8.0.0 (March 12, 2026). oxc-minify alpha (announced March 2025). Benchmark data sourced from first-party oxc-project repos (bench-linter, bench-transformer) and the independent minification-benchmarks repo. Machine specs from benchmarks: M2 Max (12 cores) and M4 Max; GitHub Actions CI for transformer benchmarks.

What Oxc is

Oxc (the Oxidation Compiler) is not a single tool. It’s a collection of JavaScript and TypeScript toolchain primitives written in Rust, maintained under the oxc-project umbrella. The components:

Parser — produces the shared AST
Oxlint — linter
Transformer — TypeScript/JSX → ES2015+ transpilation
Rolldown — bundler
oxc-minify — minifier (alpha)
Resolver — Node.js module resolution (internal use only)

The architectural bet: every component shares the same Rust parser and AST. Parsing happens once per file regardless of how many tools run on it. That’s the source of the speed numbers — not just that Rust is fast, but that you’re not re-parsing for each pass.

Oxlint — adopt now

Oxlint v1 went GA in June 2025 shipping over 500 rules; the rule set has grown since — the current linter docs list over 813 built-in rules (oxc.rs/docs/guide/usage/linter). At the beta milestone (March 2025), the team ran it against large open-source repos and got these numbers showing the v1 beta’s improvement over the first GA release (December 2023, 205 rules):

Codebase	Files	Oxlint beta time	First GA (Dec 2023) time	Speedup
microsoft/vscode	5,703	0.792s	1.697s	2.14× (beta over GA, same codebase)
elastic/kibana	68,591	3.11s	6.02s	1.94×
vuejs/core	1,063	89ms	217ms	2.44×

Those are v1 beta vs the first GA release (December 2023). The more dramatic comparison is oxlint vs ESLint v9 on non-type-aware rules:

VS Code codebase, M2 Max (12 cores): 62× faster than ESLint v9
Same codebase, M4 Max: 118× faster

The scaling with core count isn’t marketing — Rust’s multithreading is the reason. ESLint runs single-threaded by default.

Type-aware rules are the weaker story. Against typescript-eslint on Vue Core (24 identical rules), oxlint clocks in at ~8× faster on M2 Max. That caveat is methodological: the ESLint config used allowDefaultProject with a high file limit, which the config itself flagged as slowing linting. Take the 8× figure as a rough lower bound.

JS plugins alpha (March 2026). The one historic gap in oxlint — you couldn’t run ESLint JS plugins through it — closed in March 2026. Oxlint now loads existing ESLint JavaScript plugins via a JS bridge alongside its native Rust rules. The bridge slows it down compared to native-only mode, but the result is still 4.8× faster than ESLint:

Node.js repo (6,298 files, 104 Rust rules + 75 JS plugin rules + 23 custom JS rules): 21 seconds vs ESLint’s 1:43.

This matters for projects with heavy custom ESLint plugins (accessibility, custom org rules). You no longer have to choose between oxlint’s speed and your plugin ecosystem.

Migration path. The recommended approach is to run oxlint alongside ESLint, not instead of it. Install eslint-plugin-oxlint and it automatically disables the ESLint rules that oxlint covers. You get the fast oxlint pass for the rules oxlint covers (over 813 and growing), and ESLint handles the rest. Add oxlint to CI first, confirm no false positives, then gradually remove ESLint rules as oxlint coverage grows. Full ESLint removal makes sense when your project’s custom plugin requirements can move to the JS plugins bridge.

npm install --save-dev oxlint eslint-plugin-oxlint

Then in your ESLint config:

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

export default [
  ...oxlint.buildFromOxlintConfigFile('.oxlintrc.json'),
];

Official migration guide: oxc.rs/docs/guide/usage/linter/migrate-from-eslint

If you’re weighing an all-in-one formatter+linter alternative, Biome vs ESLint covers that comparison directly.

Rolldown — you get this with Vite 8

Rolldown shipped as the default bundler in Vite 8.0.0 on March 12, 2026. If you upgrade to Vite 8, Rolldown is on. No extra configuration required. Coming from Webpack? The Webpack to Vite migration guide walks through the full switch including plugin compatibility.

What changed under the hood: Vite 7 used esbuild for the dev server and Rollup for production builds. Vite 8 replaces both with Rolldown. One bundler, two modes, same output semantics.

The immediate wins:

ESM/CJS interop without @rollup/plugin-commonjs — Rolldown handles it natively, following esbuild’s interop semantics. (Caveat: the docs say “largely” esbuild semantics, not an exact 1:1.)
Built-in Oxc transformer — TypeScript, JSX, and modern syntax compile without an extra plugin.
Unified pipeline — dev and prod use the same Rolldown engine, so dev/prod parity surprises should decrease.

Known gaps. Some ES2025 regex features are unimplemented. External require() calls aren’t always auto-converted to import in ESM output. Legacy decorators and decorator metadata are supported (rolldown.rs/guide/notable-features).

Standalone Rolldown (outside Vite): possible, and Rolldown v1.0 ships a Rollup-compatible API. But the plugin compatibility with the full Rollup ecosystem is still maturing. The safe path for standalone use is “test your plugin list before committing.”

Ecosystem status:

Vite 8 — full integration, production-ready
Nuxt / SvelteKit — both use Vite, so you get Rolldown on upgrade
Next.js / Turbopack — no integration; Next.js builds on its own Rust-based toolchain
Webpack 5 — no official Oxc integration; community loaders are experimental

Transformer — stable, but use it via Rolldown

The Oxc transformer compiles TypeScript, JSX, and modern syntax to ES2015+. It’s the same component Vite 8 and Rolldown use internally. In that context it’s production-ready. Direct standalone use is possible but early-adopter territory.

Speed, from first-party benchmarks on GitHub Actions CI:

Transform type	vs SWC	vs Babel
TypeScript/JSX (typical file)	3–5× faster	20–50× faster
Peak (UserSettings.tsx + React Refresh)	5.71×	64.39×
Memory	20% less	70% less
Package size	2 MB (vs SWC’s 37 MB)	2 MB (vs Babel’s ~170 packages)

Isolated declarations (.d.ts emit):

File	vs tsc
UserSettings.tsx (124 lines)	44× faster
parser.ts (10,777 lines)	~21× faster

Important: isolated declarations are per-file annotation stripping only. You still need tsc for full type-checking. The transformer does not replace the TypeScript compiler for type errors.

Community reality check. The headline transformer multipliers (3–5× vs SWC, 20–50× vs Babel) are first-party. HN threads and community migration reports cite 30–40% real-world improvement over SWC, significantly more conservative than the peak benchmarks. Both are plausible — benchmarks measure a single hot path; real projects have cold starts, plugin overhead, and varied file shapes. Plan for 30–40%, treat the 5× as a ceiling. For a broader view of how SWC and esbuild stack up outside the Oxc ecosystem, see esbuild vs SWC 2026.

If you’re on Vite 8, you already have the transformer. If you want direct access outside Vite:

npm install oxc-transform

Decorators are supported: use { decorator: { legacy: true } } for TypeScript’s experimentalDecorators. To also emit decorator metadata, add emitDecoratorMetadata inside the same decorator key: { decorator: { legacy: true, emitDecoratorMetadata: true } }. See oxc.rs/docs/guide/usage/transformer.

oxc-minify — wait

oxc-minify is in alpha. The benchmark on typescript.js (10.95 MB) shows it outpacing esbuild:

Tool	Output size	Gzipped	Time
oxc-minify	3.35 MB (−69%)	860.67 kB (−54%)	444ms
esbuild	3.49 MB (−68%)	915.55 kB (−51%)	492ms
SWC	3.32 MB (−70%)	858.29 kB (−54%)	2,179ms
Terser	—	—	>10s (timed out)

The benchmark data above is from the first-party oxc-minify alpha announcement. The independent minification-benchmarks repo (updated April 2026) shows oxc-minify consistently placing in the top two or three across all tested files, with the fastest raw execution time on most bundles — though it doesn’t always produce the smallest output compared to compression-focused tools.

More importantly: constant inlining and aggressive dead code elimination aren’t implemented yet. Those features are planned, but without them oxc-minify’s output is larger than Terser on production-diverse codebases. Don’t use it as a drop-in Terser replacement in a production pipeline. Watch the alpha maturation and re-evaluate when the DCE story is complete.

Production readiness — the table

Component	Status	Recommendation
Oxlint	✅ Production (v1 GA Jun 2025)	Adopt now. Use `eslint-plugin-oxlint` for gradual migration.
Transformer	✅ Production (via Rolldown/Vite 8)	Use via Vite 8. Direct standalone use is early-adopter.
Rolldown	✅ Production (via Vite 8.0, Mar 2026)	Upgrade Vite 7 → 8. Watch ESM interop edge cases.
oxc-minify	⚠️ Alpha	Track; don’t ship to production yet.
Parser	✅ Stable (internal)	Not a direct adoption decision.

The case for and against right now

Adopt oxlint if your ESLint run takes more than 10 seconds on CI and you have a large repo. The parallel speedup is real, the rule set is wide enough for most teams (over 813 rules and growing, plus JS plugins alpha for the rest), and the migration story via eslint-plugin-oxlint makes it reversible.

Upgrade to Vite 8 if you’re already on Vite 7 and haven’t hit known breakage. Rolldown’s unified bundler reduces one class of dev/prod parity bug. The upgrade cost is a weekend of checking your plugin list against the known gaps (some ESM interop edge cases, some ES2025 regex features).

Don’t rush the minifier or the standalone transformer. The alpha isn’t ready for production workloads, and the transformer is best consumed via Rolldown rather than wired up separately. Adding build tooling that the project itself flags as alpha is the kind of thing that costs you half a day when it breaks quietly in a month.

Caveats

Transformer and parser benchmark multipliers are first-party (oxc-project repos). Independent community benchmarks are scarcer and more conservative. Treat the published numbers as upper bounds.
The 8× type-aware linting speedup carries a methodological asterisk. The ESLint config itself noted that the allowDefaultProject setting was configured in a way that slows linting. Real-world speedup for type-aware passes may be lower.
Rolldown’s ESM/CJS interop is documented as “largely” matching esbuild, not exactly. Unusual interop patterns may surface edge cases.
oxc-minify is missing constant inlining and aggressive DCE. It is not a drop-in for Terser on complex production bundles.
This project moves quickly. Check version numbers and changelogs before acting on specific benchmark figures.

References

Oxc GitHub — source of truth for the current component list
Oxlint v1 beta announcement (March 2025) — benchmark methodology, rule counts
bench-linter (first-party) — hyperfine benchmarks, ESLint v9 vs oxlint
Oxlint JS plugins alpha (March 2026) — JS bridge, Node.js repo benchmark
bench-transformer (first-party) — SWC/Babel comparisons on GitHub Actions CI
oxc-minify alpha announcement (March 2025) — minifier benchmarks
Vite 8.0.0 announcement (March 12, 2026) — Rolldown as default bundler
Rolldown notable features — known gaps, interop semantics
privatenumber/minification-benchmarks — independent minifier comparison (April 2026 update)
ESLint → oxlint migration guide — official
Oxlint built-in rules — current rule count (813+)
oxc-transform docs — decorator configuration options
Oxlint v1 stable announcement (June 2025)