ESLint vs Biome vs Oxlint: 56x Faster Linting [2026]

Every JavaScript and TypeScript team eventually asks the same question: is it time to drop ESLint? For a decade the answer was almost always no, since nothing else came close to its plugin depth. That changed once Rust-based tooling matured. Biome now bundles a linter and formatter in one binary, and Oxlint, built on the Oxc project backed by Vite creator Evan You, claims lint runs dozens of times faster than the JavaScript-based original. By August 2026 the choice between ESLint, Biome, and Oxlint has become one of the most searched decisions in the coding-tools space, and the right answer depends heavily on codebase size, plugin dependencies, and how much CI time your team is willing to burn.

This comparison breaks down version history, published benchmarks, download and star counts, rule parity, type-aware linting, migration paths, and the surprising corporate news (a Cloudflare acquisition) that now sits behind Oxlint’s roadmap. We’ll also build a real cost model showing what slow linting actually costs a team in CI compute minutes, and close with a data-backed verdict for five different team profiles.

·

Google · Preferred Sources

Don't miss new tech stories on Google

Add Tech Insider once in the Google app and our stories appear in your news suggestions.

Add Now

What Are ESLint, Biome, and Oxlint?

All three tools solve the same core problem: catching bugs and style violations in JavaScript and TypeScript before code ships. They solve it with three different architectures, and that architecture choice drives almost every other difference in this comparison.

ESLint: the JavaScript-native original

ESLint has been the default JavaScript linter since 2013, and it’s written in JavaScript, running on Node.js like the code it inspects. That self-hosted design is exactly why its plugin ecosystem became so deep: any developer who can write JavaScript can write an ESLint rule or plugin without learning a second language. The project has kept innovating even as Rust-based rivals chase its lead: ESLint v9.26.0 added built-in MCP server support on May 2, 2025, letting AI coding assistants query lint rules and results directly. ESLint 10.0.0 shipped in February 2026 and, according to ESLint’s own release notes, made flat config (eslint.config.js) the only supported configuration format, formally retiring the old .eslintrc system. The line has since moved to v10.13.0, which ESLint published on 16 Oct, 2026 as a minor release following v10.12.0 on 02 Oct, 2026, with the ESLint Blog reporting the minor upgrade directly, and ESLint has formally marked the entire v9.0.0–v9.39.5 line end-of-life, with ESLint v9.x reaching end-of-life on 2026-08-06, closing out more than two years of releases on that major version according to ESLint’s version support table.

Biome: the all-in-one Rust toolchain

Biome is a single Rust binary that replaces both ESLint and Prettier, handling linting and formatting in one pass with one config file. It grew out of the Rome project after that codebase was forked and rebuilt, and it markets itself as a zero-dependency swap for teams tired of maintaining two separate toolchains plus their integration plugins. Biome’s 2.x line added type-aware linting rules in 2025 and 2026, with Biome 2.4 launching in February 2026 alongside Biotype type-aware linting, according to ToolChew. The project has kept moving since: Biome 2.6, published October 15, 2026, ships support for Markdown, YAML and SCSS with both formatting and linting, and the 2.x series is a stable release credited with fully replacing both Prettier and ESLint in one binary. Vercel has publicly sponsored Biome 2.0 development, giving it one of the more visible corporate backers among the Rust-based challengers.

Oxlint: the speed-first challenger from the Oxc project

Oxlint is the linter piece of Oxc, a Rust-based JavaScript/TypeScript toolchain that also includes a parser, resolver, transformer, and the oxfmt formatter. Oxc is the technical foundation behind Rolldown, the Rust bundler that now powers Vite 8’s default production build. Oxlint reached v1.0 GA on June 9, 2025, with the Oxc Project claiming 50-100x speedups over ESLint right out of the gate and, according to ToolChew, more than 650 native Rust rules at launch. Support for JavaScript plugins reached alpha in March 2026, and the newest confirmed release is reportedly Oxlint v1.89.0 on October 19, 2026, bundled with oxfmt v0.74.0, with its rule count continuing to grow fast over that same year, according to release trackers. Unlike Biome, Oxlint doesn’t try to replace your formatter, it focuses purely on catching problems fast and is explicitly designed to run alongside ESLint during a gradual migration rather than force an all-or-nothing switch.

ESLint vs Biome vs Oxlint: Full Specs Comparison

Here’s how the three tools stack up on the specs that matter most when you’re choosing a linter for a real production codebase in 2026.

Category	ESLint	Biome	Oxlint
Latest version (Oct 2026)	10.13.0	2.6	1.89.0 (with oxfmt 0.74.0)
Language / runtime	JavaScript (Node.js)	Rust, compiled binary	Rust, compiled binary (Oxc)
Formatter included	No (pair with Prettier)	Yes, built in	No (pair with Prettier or oxfmt)
Config format	Flat config only since v10	Single biome.json	Single .oxlintrc.json, reads ESLint flat config
Est. weekly npm downloads	~134M	~8.8M	~6.7M
Est. GitHub stars	~27K–27.5K	~24K	~17K–22K
Type-aware linting	Mature, via typescript-eslint	Added in 2.x line, no full TS compiler	In progress, via tsgo integration
Plugin ecosystem size	Largest by far	Small, curated rule set	Smallest, growing fast
10K-file lint benchmark	~45.2 seconds	~0.8 seconds	Faster than Biome in most independent tests
License	MIT, free	MIT, free	MIT, free
Backing organization	OpenJS Foundation	Biome team, sponsored by Vercel	Oxc / VoidZero, joined Cloudflare in 2026
Best fit	Legacy codebases, deep plugin needs	New projects wanting lint + format in one tool	Large monorepos bottlenecked on CI time

A few numbers deserve a caveat. Download and star counts vary by several million depending on which week a tracker sampled and which package variant it counted (Biome ships as @biomejs/biome plus platform-specific binaries, for instance). The figures above use the most conservative, most consistently reported estimates from 2026 comparison trackers rather than the highest headline claims some blogs published.

Speed Benchmarks: How Much Faster Is Rust, Really?

Speed is the entire reason Biome and Oxlint exist, so the benchmark numbers matter more here than in most tooling comparisons. Independent testing in April 2026 from I Programmer put Oxlint’s edge at a 50x to 100x performance improvement over ESLint across a 500-plus-rule set, a June 2026 benchmark run on an Apple M3 Pro against a 180,000-line-of-code repository measured Oxlint finishing in 0.31 seconds versus Biome’s 0.9 seconds and ESLint’s 14.2 seconds, and a separate May 2026 test from CodeClash clocked Oxlint linting an 847-file project in just 1.4 seconds against Biome’s 4.1 seconds on that same codebase, while an October 2026 ShopperCove test of 317 files measured Biome 2.5.15 finishing in 0.41 seconds against 18.7 seconds for ESLint 9.39.4 plus Prettier 3.8.4. The most recent full 10,000-file sweep, tracked as of August 2026, held ESLint at 45.2 seconds against Biome’s 0.8 seconds and Oxlint’s roughly 0.7 seconds, keeping that Biome-over-ESLint gap at about 56x. Several separate 2026 tests point in the same direction even though the exact multipliers differ.

• A widely cited 10,000-file benchmark had ESLint finish in 45.2 seconds against Biome’s 0.8 seconds, a roughly 56x gap.
• A separate monorepo test on a 10,000-line codebase measured ESLint plus Prettier at 3–5 seconds versus Biome finishing in about 200 milliseconds.
• One team’s documented migration off ESLint and Biome onto Oxlint and oxfmt cut a full lint-and-format pipeline from roughly 81 seconds to 2.5 seconds, with the lint step alone dropping from about 3 seconds to 0.7 seconds.
• Testing against the Node.js repository itself (6,298 files), Oxlint finished in 21 seconds compared with 1 minute 43 seconds for ESLint, a 4.8x gap on a codebase most JavaScript engineers know well.
• Head-to-head, Oxlint has been clocked processing roughly 11,774 files per second against Biome’s approximately 5,887 files per second in one comparison, suggesting Oxlint edges out Biome on raw lint-only throughput even though Biome remains dramatically faster than ESLint.

The pattern across every test: Biome and Oxlint both beat ESLint by an order of magnitude or more on large codebases, and Oxlint tends to edge out Biome specifically on pure linting throughput because it doesn’t carry formatting logic in the same pass. A Vue Fes Japan test published in October 2025 clocked Oxlint at 0.022 seconds against ESLint’s 3.001 seconds on the same codebase, roughly a 136x gap, and a March 2025 benchmark of the Oxlint beta, revisited by ToolChew in June 2026, measured it completing a full lint pass in 499.6 milliseconds, roughly 62x faster than ESLint, on an Apple M2 Max testing a VS Code-scale codebase, while a separate June 2026 DevToolbox study running three different repos found Oxlint averaging roughly 50x faster than ESLint and 2 to 3x faster than Biome, a gap a Sourcetrail comparison corroborated as of August 2026, clocking Oxlint at roughly 11,774 files processed per second against Biome’s approximately 5,887, a 2x-class edge that held across multi-project tests. None of this means ESLint is unusably slow on a small project. On a 200-file app the wall-clock difference between 0.5 seconds and 2 seconds barely registers. The gap only becomes painful once a codebase crosses into the thousands of files that large monorepos routinely hit.

Downloads, GitHub Stars, and Adoption Signals in 2026

Raw popularity still favors ESLint by a wide margin. Weekly npm download trackers put ESLint at roughly 134 million downloads in a single week in May 2026, dwarfing Biome’s approximately 8.8 million and Oxlint’s approximately 6.7 million in the same window. That gap reflects ESLint’s decade-long head start and the fact that huge swaths of the npm ecosystem still list it as a peer dependency even in projects that don’t actively run it.

GitHub stars tell a similar but less lopsided story: ESLint sits around 27,000 to 27,500 stars, Biome trails at roughly 24,000, and Oxlint ranges from about 17,000 to 22,000 depending on the tracker. Star counts are a weaker adoption signal than downloads, since a star reflects interest rather than production use, but the relatively narrow gap shows how much attention the Rust-based challengers have pulled in a short time. Oxlint in particular launched its linter well after Biome and has already closed most of the star-count distance.

Growth trajectory matters more than the snapshot. Multiple 2026 trackers describe Biome’s and Oxlint’s download counts as having grown several times over in roughly a year, while ESLint’s download count has stayed roughly flat as the established default. If that trend holds, the download gap will keep narrowing even if ESLint keeps its lead through 2027.

The Oxc Story: VoidZero, Rolldown, and the Cloudflare Deal

Oxlint doesn’t exist in isolation, and understanding its backing explains why it’s suddenly showing up in every 2026 tooling roundup. Oxc is the Rust toolchain that also builds Rolldown, the bundler that replaced Rollup as Vite’s default production backend starting with Vite 8, which shipped on March 12, 2026. Vite’s own announcement described Rolldown as 10 to 30 times faster than the Rollup-based pipeline it replaces in production builds.

The company steering that work, VoidZero, was founded by Evan You, the creator of Vue and Vite. In June 2026, VoidZero announced it was joining Cloudflare, folding Vite, Rolldown, and Oxc (and by extension Oxlint) under Cloudflare’s stewardship while publicly committing to keep the tooling vendor-neutral. That deal matters for anyone evaluating Oxlint today: it’s no longer a small side project competing for attention against a well-funded rival, it’s now backed by one of the largest infrastructure companies on the internet, with a direct line to the same team responsible for Vite and Rolldown’s roadmap.

For teams already running Vite 8 with Rolldown, adopting Oxlint means staying inside a single vendor’s toolchain end to end, which is a real operational advantage even before you weigh the speed numbers. VoidZero’s own 2026 messaging has leaned hard into this framing, describing Oxlint’s roadmap as “true type-aware linting powered by tsgo,” a reference to Microsoft’s Go-based TypeScript compiler rewrite that shipped its own 10x compile-speed gains in 2026.

It’s worth understanding what Oxc actually is beyond the linter, since that scope explains why Cloudflare found it worth acquiring. The project bundles a JavaScript and TypeScript parser, a module resolver, a code transformer, and a minifier, all written in Rust and designed to share the same underlying data structures so tools built on top of them don’t pay a serialization tax passing data between stages. Oxlint and oxfmt are simply the linter and formatter built on that shared foundation, which is also why Oxlint’s roadmap is tied so closely to Rolldown’s: they’re drawing from the same parsing and analysis layer rather than maintaining separate ones.

IDE and Editor Support in 2026

A linter that’s fast in CI but sluggish in the editor doesn’t actually fix the problem most developers care about: the red squiggly line that shows up seconds after you’ve already moved to the next function. ESLint’s VS Code extension has had a decade to mature, and it remains the deepest editor integration of the three, with support for quick fixes, rule-specific documentation links, and per-workspace config resolution that handles monorepos with multiple ESLint configs in different subfolders.

Biome ships an official VS Code extension plus first-party integrations for IntelliJ-based editors and Zed, reflecting the project’s push to be a true drop-in replacement rather than a CLI-only tool. Because Biome runs as a single Rust binary, its editor extension tends to feel faster on large files than ESLint’s Node-based language server, particularly noticeable when a file crosses a few thousand lines and ESLint’s extension starts to lag behind keystrokes.

Oxlint’s editor story is the least mature of the three, which tracks with it being the youngest project. Its VS Code extension exists and works, but 2026 migration write-ups repeatedly flag a gap between how quickly the CLI ships new rules and how quickly the editor extension catches up, sometimes by days or weeks. For a team running Oxlint purely as a CI gate that’s a non-issue. For a team hoping to replace ESLint’s editor experience entirely, it’s worth testing before committing.

Developer Sentiment: What the 2026 Conversation Actually Sounds Like

Hard survey numbers specifically comparing ESLint, Biome, and Oxlint satisfaction scores are thinner in 2026 than the download and benchmark data, but the shape of the public conversation is consistent across dozens of blog posts, GitHub discussions, and dev forum threads through the year. The dominant framing repeats itself almost word for word: a “performance war” between JavaScript’s original tooling and a new generation of Rust rewrites, with headlines claiming anywhere from 10x to 56x speedups depending on the benchmark and the codebase tested.

Skeptical voices in that conversation focus less on whether the speed claims are real, most benchmarks hold up under scrutiny, and more on whether raw speed is the right axis to optimize for on a mature codebase that already has its linting pipeline cached and parallelized in CI. That’s a fair pushback: a team whose ESLint run already finishes in eight seconds because of aggressive caching won’t feel the same 56x win a team with an uncached 45-second run experiences. The debate that gets less attention but matters more long-term is the tsgo and type-aware linting question, since that’s the capability gap that actually determines whether Biome or Oxlint can fully replace ESLint on a serious TypeScript codebase rather than just supplementing it.

Rule Parity and Plugin Ecosystem Compared

Speed only matters if the tool actually catches the bugs your team relies on ESLint to catch today, and this is where the comparison gets less clean. ESLint’s plugin ecosystem, built over more than a decade, remains far deeper than either challenger’s. Thousands of published plugins cover everything from accessibility rules to framework-specific patterns to internal company style guides, and any team can write a custom rule in plain JavaScript.

Biome ships a documented migration command that imports both legacy and flat ESLint configs, but it explicitly does not migrate YAML-based configs, and it distinguishes between rules it considers “equivalent” to an ESLint rule versus rules it considers merely “inspired” by one. Only equivalent rules migrate automatically. Inspired rules need an explicit opt-in because their behavior isn’t identical. Biome’s docs list solid coverage of typescript-eslint, jsx-a11y, react, and unicorn plugin families, but that’s a fraction of the plugin universe ESLint supports.

Oxlint has moved the fastest on compatibility claims, with some 2026 sources describing an ESLint v9-compatible plugin API and migration tooling that can read an existing ESLint flat config directly. Those compatibility claims are worth verifying against your own rule set before switching, since third-party comparison sources disagree on exactly how complete that parity is today. The safest framing for any team: run Oxlint or Biome side by side with ESLint on your actual codebase and diff the findings before removing ESLint from CI.

The practical takeaway for a plugin-heavy codebase: audit your actual eslint.config.js before assuming either challenger is a drop-in swap. Count how many of your active rules come from third-party plugins versus ESLint’s own built-in rule set and typescript-eslint’s core rules. Teams whose configs lean almost entirely on typescript-eslint plus a handful of well-known plugins like eslint-plugin-react or eslint-plugin-jsx-a11y tend to see high coverage from Biome’s migration tool. Teams with heavily customized internal plugins or niche framework-specific rule sets should expect gaps that require either keeping ESLint for those specific rules or rewriting the logic from scratch.

Type-Aware Linting: ESLint, Biome, and the tsgo Bet

Type-aware linting, rules that need to know a variable’s actual type rather than just its syntax, is the single hardest capability to replicate in a fast, standalone linter, because it typically requires running a full TypeScript compiler pass. ESLint paired with typescript-eslint remains the most mature option here in 2026 and is still the reference point every other tool gets measured against.

Biome added type-aware rules in its 2.x release line without running the full TypeScript compiler, instead approximating type information well enough to cover a large share of common cases. That’s a meaningful engineering trade-off: it keeps Biome fast, but it means Biome’s type-aware coverage isn’t a full substitute for typescript-eslint on codebases with unusual or highly generic type patterns.

Oxlint is taking a different path, building toward type-aware linting powered by tsgo, the Go-native rewrite of the TypeScript compiler that Microsoft shipped as TypeScript 7.0 on July 8, 2026. Because tsgo delivers roughly 10x faster full builds than the old JavaScript-based compiler on large codebases, Oxlint’s bet is that it can eventually offer full type-aware linting without giving up the speed advantage that defines the tool. A July 2026 Rust-tooling review from Dayfing, pegging the release at v1.75.0, found Oxlint’s type-aware rules had reached stabilization on July 22, 2026, a real milestone on that roadmap, but broader coverage was still rounding into shape as of August 2026, so teams that need comprehensive type-aware linting today should treat full parity with typescript-eslint as a work in progress rather than a finished feature.

Pricing and the Real Cost of Slow CI

All three tools are free and open source with no paid tier, no enterprise license, and no usage caps. That makes a traditional pricing table pointless, but it doesn’t mean the choice is cost-neutral. Lint time is billed CI compute time, and GitHub Actions charges $0.006 per minute for a standard Linux runner. Using the benchmark numbers above, here’s what that gap actually costs a team running lint checks on every pull request push.

Scenario	ESLint runtime	Biome runtime	Oxlint runtime	Monthly CI cost at 200 runs/day (ESLint)	Monthly CI cost at 200 runs/day (Rust tool)
10,000-file repo, full lint	45.2s	0.8s	~0.7s (comparable range)	~$18.10	~$0.32
10,000-line monorepo, lint+format	3–5s	~0.2s	n/a (no formatter)	~$1.60	~$0.08
Node.js-scale repo (6,298 files)	103s	n/a	21s	~$41.20	~$8.40

These figures use GitHub’s published standard Linux runner price and the benchmark timings cited earlier in this article. They’re an estimate, not a guarantee, since actual CI cost also depends on runner tier, caching, and how often lint actually runs per day. The direction is what matters: on a large monorepo running hundreds of CI jobs daily, the difference between ESLint and a Rust-based linter can add up to real, budgeted infrastructure spend, not just a developer-experience nicety. That’s before counting the human cost of engineers waiting on a slow pre-commit hook dozens of times a day.

Real-World Examples: How Teams Are Using These Tools

A handful of documented cases from 2025 and 2026 show how this plays out beyond synthetic benchmarks. What ties these examples together is that none of them describe a clean, one-shot replacement. Every real migration involved running two tools side by side for a stretch, measuring the actual difference on production code rather than trusting a vendor’s marketing benchmark, and only then deciding whether to fully commit.

1. The 81-second-to-2.5-second pipeline migration. One documented team migration moved a combined ESLint, Biome, and Prettier pipeline to Oxlint and oxfmt and measured the full check step dropping from roughly 81 seconds to 2.5 seconds, a change significant enough to shift how often engineers ran checks locally instead of waiting for CI.
2. Node.js as a benchmark target. Testers used the Node.js project’s own 6,298-file codebase, a repo most backend engineers recognize, as an Oxlint benchmark and measured 21 seconds versus roughly 103 seconds for ESLint, giving the comparison real-world credibility beyond a synthetic file generator.
3. Biome’s Vercel sponsorship. Vercel has publicly backed Biome 2.0 development, a signal that at least one major frontend infrastructure company sees enough value in the all-in-one Rust toolchain to fund it directly rather than simply adopting ESLint by default.
4. Vite 8 adoption at scale. Teams on the Rolldown-based Vite 8 stack, including companies like Linear and Ramp, have reported major build-speed gains after switching bundlers, the same Oxc-adjacent ecosystem that now powers Oxlint, illustrating why Oxc-aligned teams increasingly reach for Oxlint as the natural next step rather than treating it as an isolated tool choice.
5. ESLint’s own 2025 year-in-review. The ESLint project’s official 2026 retrospective on the prior year documents the flat-config transition, which became the default with v9.0.0 back in April 2024 and by 2025 required Node 18.18.0 or newer, plus continued plugin ecosystem growth, underscoring that ESLint isn’t standing still even as competitors highlight its speed disadvantage. The team also called out multithreaded linting, shipped in v9.34.0 during 2025, as one of the year’s key performance wins, alongside smaller releases like v9.20.0’s improved empty-config handling on February 7, 2025.

Framework and Build Tool Compatibility

Linters don’t run in a vacuum, and how well each tool plays with the rest of a modern JavaScript stack matters as much as raw benchmark numbers. ESLint’s flat config was explicitly designed to make framework-specific presets easier to compose, and nearly every major framework, Next.js, Nuxt, SvelteKit, Angular, ships an official or community-maintained ESLint config out of the box. That coverage is the direct product of ESLint’s decade-plus head start and its plugin API being simple enough for framework maintainers to build against without deep Rust knowledge.

Biome’s framework coverage has grown quickly but unevenly. React and JSX support is strong given how central it is to the modern frontend stack, and Vue support has improved through 2025 and 2026, but more niche framework combinations sometimes lag behind what an equivalent ESLint plugin already covers. Oxlint’s framework-specific rule coverage is the newest of the three and growing the fastest in absolute percentage terms, precisely because it started from a smaller base, but teams on frameworks outside the React and Vue mainstream should test their specific stack before assuming full coverage.

One practical wrinkle worth flagging: because Oxlint and Rolldown share the same Oxc parsing layer, framework support tends to arrive on a coordinated schedule tied to the broader Oxc/Vite roadmap rather than as an independent Oxlint release cycle. That’s good news if you’re already deep in the Vite 8 ecosystem, since new framework support often lands in lockstep with bundler updates you’re already pulling in. It’s a smaller advantage if your team uses a non-Vite build pipeline, where Oxlint’s framework rule coverage has to stand on its own.

How Biome’s Language and Tailwind Coverage Has Grown

Biome’s own release announcements show how quickly its coverage has widened. Biome 2.5 crosses 500 lint rules, ships code fixes for GritQL plugins, adds the delimiterSpacing formatter option, watcher mode, concise reporter, and more than 70 rules stabilized. Biome 2.6 then ships support for three new languages: Markdown, YAML and SCSS, with both formatting and linting supported. The YAML parser ships with 100% conformance coverage against the official test suite, and the formatter has 100% compatibility with Prettier.

Tailwind users get specific attention as well. Biome 2.6 brings Tailwind-aware linting and class sorting closer to the way developers like to use Tailwind in their projects. The noTailwindRawColors rule debuted in 2.5.15, and in 2.6.0 it actively suggests existing colors in your design system, if any are close. For teams sharing configuration across repositories, Biome 2.6 introduces the resolutionKind option for object-syntax plugin entries, making plugins easier to reuse from shared configurations.

For a team weighing a switch, these additions matter most when the repository contains Markdown, YAML or SCSS files, or relies on Tailwind class conventions. Check which of those file types you actually have, run Biome against them next to your existing setup, and compare the findings before removing anything. On the Oxlint side, Oxlint v1.87.0 was released on October 5, 2026 alongside Oxfmt v0.72.0, and Oxlint v1.86.0 arrived on September 28, 2026 alongside Oxfmt v0.71.0, so test the linter and formatter versions together rather than in isolation.

Migration Guide: Moving From ESLint to Biome or Oxlint

Neither migration should happen in one commit on a codebase of any real size. Both tools include a compatibility path specifically because full parity with ESLint’s rule set isn’t guaranteed. The safest approach runs the new linter in parallel with ESLint for at least one sprint before removing anything.

Migrating to Biome

Start by installing Biome and running its built-in migration command, which reads your existing ESLint and Prettier configuration and generates a starting biome.json.

npm install --save-dev --save-exact @biomejs/biome
npx @biomejs/biome migrate eslint --write
npx @biomejs/biome migrate prettier --write
npx @biomejs/biome check --write ./src

After the migration command runs, open the generated config and check for rules Biome flagged as “inspired” rather than “equivalent.” Those need manual review since their behavior may differ slightly from the ESLint rule they replace. Keep ESLint installed and run both tools in CI for a sprint, comparing diffs before you delete the ESLint config and its dependencies.

Migrating to Oxlint

Oxlint is explicitly designed to run alongside ESLint rather than replace it outright on day one, since it doesn’t yet cover the full plugin surface. Add it as a fast first pass and keep ESLint for the rules it doesn’t yet support.

npm install --save-dev oxlint
npx oxlint --init
npx oxlint ./src
# Keep ESLint running for plugin-specific rules Oxlint doesn't cover yet
npx eslint ./src --max-warnings=0

A common pattern in 2026 migration write-ups: run Oxlint first in CI as a fast fail-fast gate that catches the majority of issues in under a second, then run ESLint afterward only for the smaller set of plugin-dependent rules Oxlint hasn’t replicated yet. That combination captures most of the speed win without giving up plugin coverage, and it’s a lower-risk stepping stone than a full cutover.

Common Migration Pain Points

A few friction points show up repeatedly in 2026 migration reports, and knowing them ahead of time saves debugging time later.

• ESLint 10’s mandatory flat config means teams still on the old .eslintrc format have to migrate that first, before they can even evaluate Biome or Oxlint’s own ESLint-config importers, which expect flat config as input.
• Biome’s migration tool skips YAML-based ESLint configs entirely, so any team using .eslintrc.yml needs to convert to JSON or JS first.
• Custom, hand-written ESLint rules have no automatic migration path to either Biome or Oxlint, since both tools use their own internal rule engines rather than ESLint’s plugin API for rule authoring.
• Editor integration can lag behind CLI support. Teams have reported IDE extensions catching up to new Biome or Oxlint releases days or weeks after the CLI ships.
• Formatter conflicts are common during a transition period if a team runs Biome’s formatter and Prettier simultaneously without fully removing one, producing conflicting diffs on save.

Use Cases: Which Linter Fits Your Project

No single answer fits every team. Here’s how the choice tends to break down by project profile in 2026.

• Large enterprise codebase with deep plugin dependencies: stick with ESLint plus typescript-eslint. The plugin ecosystem and type-aware maturity aren’t fully replicated elsewhere yet, and the migration risk on a mission-critical codebase usually outweighs the CI time savings.
• New TypeScript project starting from scratch: Biome is the simplest choice, since it replaces both your linter and formatter with one dependency and one config file, cutting setup time and tooling maintenance overhead.
• CI-bottlenecked monorepo with thousands of files: Oxlint as a fast first-pass gate, paired with a slower ESLint run for plugin-specific rules, captures most of the speed benefit without a risky full cutover.
• Teams already on Vite 8 and Rolldown: Oxlint keeps the whole toolchain under one Oxc-based vendor, which simplifies debugging and version alignment across bundler, linter, and formatter.
• Solo developers and small side projects: Biome’s zero-config defaults and single binary install remove the friction of wiring up separate ESLint and Prettier configs for a project that doesn’t need extensive customization.
• Teams that need type-aware linting today, not on a roadmap: ESLint with typescript-eslint remains the only fully mature option, since both Biome’s and Oxlint’s type-aware coverage are still evolving as of August 2026.

Pros and Cons of Each Tool

Weighed against each other directly, each tool’s strengths map closely to its weaknesses.

Tool	Pros	Cons
ESLint	Largest plugin ecosystem, mature type-aware linting via typescript-eslint, huge community, most documentation and Stack Overflow coverage	Slowest of the three by a wide margin on large codebases, requires a separate formatter, config migration to flat config still trips up legacy projects
Biome	Linter and formatter in one tool, dramatically faster than ESLint, single config file, active Vercel-backed development	Smaller rule set than ESLint, type-aware linting doesn’t run the full TypeScript compiler, migration tool skips YAML configs and some plugin rules
Oxlint	Fastest raw lint throughput of the three, backed by Cloudflare via the VoidZero deal, designed to run alongside ESLint for low-risk adoption, tight integration with the Vite 8 / Rolldown stack	No built-in formatter, type-aware linting still in progress via tsgo, smallest plugin ecosystem, newest and least battle-tested of the three

The Verdict: Which Linter Should You Choose in 2026

There isn’t a single winner here, and any article claiming otherwise is oversimplifying a decision that depends on codebase size and risk tolerance. The data does point to a clear default for each situation, though.

If your team runs a large, established codebase with custom ESLint plugins and relies on typescript-eslint’s type-aware rules daily, switching away from ESLint in 2026 still carries more migration risk than it saves in CI minutes. The 134 million weekly downloads aren’t just inertia, they reflect an ecosystem depth that Biome and Oxlint haven’t fully matched yet, particularly on type-aware linting.

If you’re starting a new project or running a small-to-medium codebase without heavy custom plugin dependencies, Biome’s all-in-one design and roughly 56x speed advantage over ESLint on large lint runs make it the more pragmatic default in 2026, especially with Vercel’s continued investment behind it.

If your bottleneck is specifically CI compute time on a monorepo running thousands of files through lint checks dozens of times a day, Oxlint’s throughput advantage and its backing from Cloudflare via the VoidZero acquisition make it worth piloting as a fast first-pass gate today, with ESLint kept in the loop for anything Oxlint doesn’t yet cover. Watch the tsgo-powered type-aware linting work closely. Once that ships, Oxlint’s case for a fuller cutover gets substantially stronger.

Frequently Asked Questions

Is Biome a full replacement for ESLint and Prettier?
For most projects, yes. Biome handles both linting and formatting in one Rust binary and one config file. The gap is plugin coverage: teams relying on niche ESLint plugins or highly custom rules may still find gaps that require keeping ESLint around for specific checks.

Can I run Oxlint and ESLint together?
Yes, and that’s actually the recommended adoption path. Oxlint is designed to run as a fast first pass that catches most issues in under a second, with ESLint running afterward for plugin-specific rules Oxlint doesn’t yet replicate.

Why is Oxlint suddenly getting so much attention in 2026?
Two reasons converged: independent benchmarks showing it out-pacing even Biome on raw lint throughput, and VoidZero, the company behind Oxc, Oxlint, Rolldown, and Vite, joining Cloudflare in June 2026. That deal put Oxlint’s roadmap behind one of the largest infrastructure companies online.

Does Biome or Oxlint support type-aware linting like typescript-eslint?
Partially. Biome added type-aware rules in its 2.x line without running a full TypeScript compiler pass, covering many but not all common cases. Oxlint is building toward type-aware linting powered by tsgo, the Go-native TypeScript compiler, but that work was still in progress as of August 2026.

Will switching to Biome or Oxlint actually save my team money?
On a small project, the CI cost difference is negligible. On a large monorepo running hundreds of lint jobs a day, the gap between ESLint’s roughly 45-second run and a Rust-based tool’s sub-second run on the same codebase can translate into real GitHub Actions compute savings, on top of the developer time saved waiting on pre-commit hooks.

What happened to the Rome project, and is it related to Biome?
Biome is the community continuation of Rome after that original project’s primary maintainer stepped back. The codebase was forked and rebranded as Biome, which is why some older 2023-era comparisons still reference Rome by name.

Is ESLint 10’s flat config a hard requirement now?
Yes. ESLint 10.0.0, which shipped in February 2026, dropped support for the legacy .eslintrc format entirely, according to ESLint’s own release notes. Any project still on the old config format needs to migrate to eslint.config.js before upgrading past ESLint 9.

Do I need to migrate to Biome or Oxlint at all?
No. ESLint remains fully maintained, actively developed, and the most plugin-complete option of the three. The migration only makes sense if your team is specifically bottlenecked on lint speed or wants to consolidate tooling. There’s no forcing function requiring anyone to move off ESLint in 2026.

Sources: ESLint’s official 2025 year in review, ESLint’s flat config migration guide, VoidZero’s announcement of joining Cloudflare, Vite’s official Vite 8 announcement, the Oxc project on GitHub, Oxlint’s usage documentation, typescript-eslint’s documentation, Biome’s GitHub repository, and GitHub’s Actions billing documentation.