Biome vs ESLint 2026 — is it finally time to switch?

Switch to Biome if you are starting a greenfield TypeScript project. Stay on ESLint if your stack leans on custom rules, security plugins, or framework-specific plugins. If you are somewhere in the middle — brownfield monorepo, limited plugin surface — the hybrid path (Biome for formatting + linting basics, ESLint for the gaps) is worth a day of your time right now.

Who this is for

TypeScript developers deciding whether to replace ESLint (and Prettier) with Biome v2 in 2026. If you are building a Vue or Svelte app, or your security team mandates eslint-plugin-security, skip to where Biome falls short first.

What we tested

Biome v2.4.15 (released 2026-05-09) against ESLint 9.x + Prettier. Benchmarks are drawn from independently verified third-party measurements and Biome’s own published figures, with methodology noted for each. Where Biome published the number themselves, we’ve flagged it — self-reported benchmarks are upper bounds, not gospel.

Biome vs ESLint: findings

Speed — the numbers hold up

Biome is faster. The question is how much faster, and whether it matters for your workflow.

Scenario	ESLint + Prettier	Biome	Speedup
Lint 10,000 files	45.2 s	0.8 s	56×
Format 10,000 files	12.1 s	0.3 s	40×
Lint 500-file project	30+ s	2–3 s	10–20×
Pre-commit hook, large TS monorepo	27.2 s	1.8 s	15×
Type-aware lint, 200-file backend pkg	15 s	6 s	2.5×

The 56× figure is Biome’s own benchmark — treat it as an upper bound. The pre-commit number (15×, a 92.6% reduction) comes from a real production TS monorepo and is independently verifiable wall-clock time. The BetterStack independent measurement found 10–20× on a 500-file project.

Why is it faster? Single Rust binary, full CPU parallelism (ESLint is single-threaded by default), no Node.js startup overhead, no plugin resolution chain.

On a 50k+ LOC codebase, realistic CI savings are 30–90 seconds per run. At a few hundred runs a week, that adds up to meaningful compute budget.

Rule coverage — mostly there, with real gaps

Biome v2.4.15 ships 502 rules and covers roughly 80–94% of what teams actually use from ESLint recommended + typescript-eslint for standard TypeScript/React projects.

Category	Biome coverage
Core ESLint recommended	~94% of commonly-used rules
typescript-eslint type-aware	~75–85%
React / JSX	~90%+
Accessibility (a11y)	Partial — no alt-text rules
Import organization	Core use cases covered
React hooks (`useExhaustiveDependencies`)	Covered
Security (`eslint-plugin-security`)	❌ Not available
Framework plugins (Next.js, Vue, Svelte, Astro)	❌ Not yet stable
Custom rules	❌ GritQL plugin is v1, not production-ready

The type-aware story deserves a note. Biome v2.0 ships type-aware linting without needing the TypeScript compiler — the first tool to do that. It covers around 75–85% of typescript-eslint’s type-aware rules. The remaining 15–25% is real: if your codebase relies on deep inference for floating-promise safety or complex generics, test before switching.

Migration — one day, not one sprint

Two commands get you most of the way:

biome migrate eslint --write    # reads .eslintrc / eslint.config.js → biome.json
biome migrate prettier --write  # reads .prettierrc → biome.json

It handles both legacy .eslintrc.* and flat eslint.config.js, major plugin families (TypeScript ESLint, React, Unicorn, JSX A11y), and .eslintignore. It does not handle YAML configs, cyclic references in plugin configs, or any custom rules.

Kitty Giraudel migrated a 200,000-line, 40-package monorepo in roughly one day. Her verdict: “it’s so lightweight, fast and simple to get started, I don’t see myself setting up ESLint ever again.” Caveat: she lost Cypress linting rules, and the VS Code import rewriter occasionally mangled complex import graphs.

Developers modernizing their linting stack often pair this with a Vite migration — both are Rust-backed speed upgrades that fit into the same modernization sprint.

Editor integration — functional, not battle-tested

Editor	Status
VS Code	Official extension — format-on-save, diagnostics, code actions
JetBrains / WebStorm	Native since WebStorm 2024.3+, no plugin needed
Neovim / Emacs	Via Biome’s LSP server

The VS Code extension works. The import organizer has a known mangling issue on complex import graphs — mentioned in every major migration post from 2024–2025. If you lean on auto-import reorganization in VS Code, test this before committing to the switch.

ESLint’s VS Code extension (20M+ installs) has a decade of battle-testing and richer per-rule documentation in the hover popup. The gap is real and will close, but it hasn’t closed yet.

BetterStack found output matched exactly except for a few edge cases involving comments inside JSX attributes.

Ecosystem health — active, volunteer-led

Biome is a healthy, active project — not a stagnation risk. But it is volunteer-led:

v2.4.15 released 2026-05-09; weekly patch cadence (~every 7–10 days)
24,676 GitHub stars, 992 forks, ~16 core maintainers (up from 10 in 2024)
15M+ monthly downloads
Sponsored by Vercel (funded v2.0’s type-aware linting) and Depot
Not VC-backed; revenue via Open Collective + GitHub Sponsors + Enterprise Support contracts

The single risk worth naming: contributor concentration. A project with ~16 maintainers and no corporate owner could stall if key contributors move on. With 15M downloads and Vercel backing, that risk is lower than it was in 2023, but it is not zero. If you are making a five-year bet, keep ESLint migration docs current.

Verdict

Switch to Biome if:

You are starting a greenfield TypeScript or React project
CI lint time is a real pain point and your plugin surface is limited
You rely on ESLint recommended + typescript-eslint + eslint-plugin-react — Biome covers this well today
You are running a monorepo and want nested config support without the overhead

Stay on ESLint if:

Your team has custom ESLint plugins
You depend on eslint-plugin-security, eslint-plugin-next, eslint-plugin-vue, or eslint-plugin-svelte
Full typescript-eslint type-aware coverage is non-negotiable
You need the IDE documentation depth of the ESLint VS Code extension

Hybrid path (brownfield projects): Run Biome as your formatter and use it for the lint rules it covers. Keep ESLint for the gaps — framework plugins, custom rules, security linting. Run both in CI. This is the current best-practice approach for teams that want the speed wins without a hard cut. Teams completing this modernization often also switch to Vitest for testing — the same speed-first philosophy applied to the test runner.

Caveats

Three things this article did not test:

Biome’s custom rule system (GritQL) — it shipped in v2.0 but is first-iteration. We did not attempt to port real production custom rules. Do not assume it handles your use case without testing.
Framework-specific plugin equivalents — no independent test of how well Biome’s built-in Next.js or Vue support handles real framework patterns. The rule tables above are from Biome’s documentation; verify against your actual plugin usage.
Long-tail type-aware edge cases — the 75–85% coverage figure is from Biome’s own documentation and BetterStack’s testing. Your specific type patterns may hit the missing 15–25%.

No affiliate links in this article. Biome is open-source; no commercial relationship here.