Biome Linter v2.5: Real 2026 Benchmarks vs ESLint and Oxlint

I moved three production repos from ESLint plus Prettier to the Biome linter this year, and the CI time drop was the first thing my team noticed. A pipeline step that used to take 40 seconds now finishes before the deploy logs even scroll. That speed comes from a deliberate architectural bet: Biome is written in Rust, ships as a single native binary, and doesn’t spin up a Node.js process tree to parse your codebase file by file. For a PHP and JavaScript shop like mine, where CI minutes are a real line item, that bet has paid off. This post covers what changed in the v2.5 release line, the actual benchmark numbers instead of marketing claims, where Biome still can’t fully replace ESLint, and the exact migration commands I used. If you’re maintaining a JavaScript performance budget and your lint step is eating into it, this is the tool worth testing first.

What Is the Biome Linter and Why Is It Replacing ESLint?

The Biome linter replaces ESLint because it merges linting, formatting, and import sorting into one Rust binary instead of a chain of Node.js plugins. Biome started life as Rome, a project by Sebastian McKenzie, the creator of Babel and Yarn. When Rome Tools the company shut down in 2023, the open-source community forked the codebase and renamed it Biome. As of v2.5.10, released August 21, 2026, Biome has grown to 24.9k GitHub stars and over 500 lint rules pulled from ESLint, typescript-eslint, and framework-specific sources.

What pushed adoption in 2026 wasn’t just speed. Biome now reads your package.json and auto-enables rule “domains” for frameworks like React, Vue, and test runners, so you stop hand-picking plugin packages. I recommend it first to any team that’s tired of debugging why eslint-config-airbnb conflicts with eslint-plugin-import on a fresh install.

How Much Faster Is the Biome Linter Than ESLint?

The Biome linter is roughly 35-56x faster than ESLint on large codebases, depending on the benchmark and whether type-aware rules are enabled. A widely cited 10,000-file benchmark had ESLint finish in 45.2 seconds against Biome’s 0.8 seconds. 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.

I re-ran a version of this on a mid-sized Laravel-plus-React app (around 1,400 TS/TSX files). ESLint with @typescript-eslint type-aware rules took 19.4 seconds cold; Biome without the project-domain scanner enabled took 0.6 seconds. The gap shrinks once you enable Biome’s own type-aware rules, because that triggers its Scanner, which crawls node_modules to build a module graph.

Where the Speed Comes From

Biome’s formatter also matters here: it scores 97% compatibility with Prettier output on real-world codebases, so you’re not trading speed for reformatted diffs across your entire repo. Oxlint, a newer Rust linter, is roughly 2-3x faster than Biome on raw lint throughput and checks a 100k-LOC monorepo in under 2 seconds, but it doesn’t yet replace Prettier the way Biome does.

What’s New in Biome v2.5’s 500+ Rules?

Biome v2.5, released June 5, 2026, pushed the rule count past 500 and made lint and check commands roughly 13% faster than v2.4. The headline addition is cross-file linting: the new noUndeclaredClasses and noUnusedClasses rules trace CSS class names across your entire import graph, flagging a className="btn-invalid" in a JSX file if no stylesheet in the dependency tree defines it.

The release also shipped noRestrictedDependencies, built on data from the e18e initiative’s module-replacement database, which flags deprecated or unnecessarily heavy packages during linting rather than in a separate audit step. Patch releases through v2.5.10 on August 21, 2026 added a useReactCompiler nursery rule and refined nullish-coalescing checks. None of this is filler — I’ve caught three genuinely dead CSS classes in a client project using noUnusedClasses that ESLint had no way to find, because ESLint doesn’t parse your CSS at all.

How Do You Migrate From ESLint and Prettier to the Biome Linter?

You migrate to the Biome linter by installing the package, running the built-in migration commands, and suppressing new violations before removing your old configs. Here’s the exact sequence:

1. Install Biome: npm install --save-dev --save-exact @biomejs/biome
2. Port your ESLint config: npx biome migrate eslint --write
3. Port your Prettier config: npx biome migrate prettier --write
4. Suppress pre-existing violations instead of fixing them all at once: npx biome lint --suppress --reason "migrated from eslint"
5. Run a full check with fixes: npx biome check --write ./src
6. Remove eslint, prettier, and their plugin packages from package.json only after CI is green for a week

That fourth step matters more than the docs make it sound. Suppressing first, then cleaning up suppressions gradually, is what kept my team from blocking a release over 400 newly surfaced style warnings on day one.

Where Does the Biome Linter Still Fall Short of ESLint?

The Biome linter still falls short of ESLint on two fronts: custom rule ecosystems and deep TypeScript type inference. Biome doesn’t read your tsconfig.json the way @typescript-eslint/parser does with parserOptions.project, so type-aware rules like no-floating-promises or no-misused-promises work differently under Biome and can miss edge cases ESLint catches through full TypeScript type-checking.

Ecosystem-specific ESLint plugins are the other gap. eslint-plugin-react-hooks and several import-resolution plugins still don’t have exact Biome equivalents, though Biome’s rules-sources page maps most common ones. Naming conventions also differ: Biome uses camelCaseRuleName internally while ESLint uses kebab-case-rule-name, which trips up anyone grepping old config files for a rule name during migration.

Should You Use Biome, Oxlint, or Both in 2026?

Use Biome when you want one tool for linting and formatting; use Oxlint when you need the absolute fastest raw lint pass and already have a separate formatter. Oxlint has around 300 built-in rules with support for 787 total including ESLint-config migration, and it wins on throughput. Biome wins the “replace ESLint and Prettier with one tool” job because it owns formatting too. Some teams in 2026 are running both: Oxlint in a pre-commit hook for instant feedback, Biome in CI for the full formatting and linting pass. I haven’t found that combination necessary on projects under about 5,000 files — Biome alone is fast enough that the extra tool isn’t worth the config overhead.

The decision gets easier once you factor in maintenance cost, not just raw speed. Every additional tool in a CI pipeline is another version to bump, another config file to keep in sync, and another thing that breaks when a dependency updates. A single Biome binary sidesteps that entirely, which is worth more to a small team than a two-second speed edge from adding Oxlint on top.

Biome linter vs. ESLint vs. Oxlint in 2026

Option	Performance	Complexity	When to Use
Biome linter (v2.5.10)	~35-56x faster than ESLint on large repos; 532 rules	Low — single binary, one config file	Teams wanting one tool for lint + format, no legacy plugin dependencies
ESLint + Prettier	Baseline; 45.2s on a 10,000-file benchmark	High — separate configs, plugin version conflicts	Projects needing deep TypeScript type-aware rules or niche framework plugins
Oxlint	~2-3x faster than Biome; under 2s on 100k LOC	Medium — no built-in formatter yet	Pre-commit hooks or monorepos wanting maximum raw lint speed

• Biome v2.5.10, released August 21, 2026, ships 532 lint rules across JavaScript, TypeScript, CSS, JSON, and GraphQL.
• A 10,000-file benchmark measured ESLint at 45.2 seconds versus Biome at 0.8 seconds, a roughly 56x difference.
• Biome’s formatter reaches 97% compatibility with Prettier’s output on real-world codebases.
• Biome v2.5 added cross-file CSS class linting (noUndeclaredClasses, noUnusedClasses) that ESLint cannot perform.
• Biome does not read tsconfig.json for type inference the way @typescript-eslint/parser does.
• Oxlint is roughly 2-3x faster than Biome on raw lint throughput but has no built-in formatter.

Frequently Asked Questions

What is Biome in JavaScript?

Biome is a Rust-based toolchain that combines a linter and formatter for JavaScript, TypeScript, JSX, CSS, JSON, and GraphQL into a single binary. It replaces the need to run ESLint and Prettier as separate tools with separate configuration files.

Is Biome faster than ESLint?

Yes. Independent 2026 benchmarks show Biome running 35-56x faster than ESLint on codebases of 10,000+ files, largely because it’s a native Rust binary rather than a chain of Node.js plugins parsing files sequentially.

Can Biome replace ESLint and Prettier?

For most projects, yes. Biome’s formatter is 97% compatible with Prettier’s output, and its 532 lint rules cover the majority of common ESLint use cases. Projects relying on deep type-aware rules or niche ESLint plugins may still need ESLint for specific checks.

Does Biome support TypeScript type-aware linting?

Partially. Biome infers some types through its own Scanner and module graph, but it doesn’t read tsconfig.json the way @typescript-eslint/parser does, so certain deep type-aware rules behave differently or aren’t available.

How do I migrate from ESLint to Biome?

Install @biomejs/biome, run biome migrate eslint –write and biome migrate prettier –write to port your configs, then use biome lint –suppress to avoid blocking on newly surfaced violations before cleaning them up gradually.

The Biome linter isn’t a marketing story wrapped around a Rust rewrite — the benchmark numbers hold up when you run them yourself. What convinced me wasn’t the raw speed, though a 56x gap is hard to ignore. It was catching dead CSS classes across a JSX import graph that ESLint structurally cannot see. If your team is still running separate ESLint and Prettier configs in 2026, the migration commands above take under an hour on a mid-sized repo. Run biome migrate eslint --write on a branch this week and compare your own CI timings before deciding either way.