Biome First Look: One Tool to Rule Them All?

Earlier posts in this series started in February: shared ESLint + Prettier packages, flat config, pre-commit hooks, then an April note on profiling slow rules. By late 2025 Biome has been stable long enough that "should we try it?" is a reasonable question for teams already on ESLint and Prettier.

This is a first look: what it consolidates, where it still loses to ESLint, and what I would measure before flipping a monorepo.

What "one tool" actually means

ESLint + Prettier means two tools, two configs, and a long ongoing debate about who owns formatting rules. Biome ships formatter + linter (and more) in one Rust binary with one config file.

json
// biome.json, illustrative starter
{
	"$schema": "https://biomejs.dev/schemas/1.9.4/schema.json",
	"formatter": {
		"enabled": true,
		"indentStyle": "tab",
		"lineWidth": 80
	},
	"javascript": {
		"formatter": {
			"quoteStyle": "single",
			"trailingCommas": "all"
		}
	},
	"linter": {
		"enabled": true,
		"rules": {
			"recommended": true
		}
	},
	"files": {
		"ignore": ["dist/**", "coverage/**", "**/*.gen.ts"]
	}
}

Consolidation wins I care about:

1. One CI step for format + lint instead of orchestrating prettier --check and eslint.
2. Speed on large trees: Rust helps when ESLint rule timing tables from April still slow you down.
3. Fewer "Prettier vs ESLint formatting rule" conflicts to keep disabled by hand.

Where ESLint still pays off

Biome’s rule story is strong and growing; it is not a full mirror of every plugin you might depend on:

I keep ESLint on day one. I run Biome in shadow mode: format + lint report on CI without failing the build, diff the findings against ESLint for two weeks, then decide.

bash
# Illustrative: fail the build later, not on first PR
pnpm exec biome check apps/web/src --reporter=github

Friction I expect on first contact

Config mental model. biome.json is not .eslintrc. Recommended sets are opinionated; turning rules off is fine, cargo-culting recommended: true into a legacy codebase will flood the diff.

Editor setup. People need the Biome extension (or LSP) and need to turn off competing format-on-save from Prettier for the same glob. Half the "Biome is broken" reports I see are two formatters fighting.

Ignore semantics. Generated files, storyshots, and *.gen.ts must be listed early or review noise hides real issues.

Monorepo layout. One root biome.json with overrides vs per-package configs, same design tension as shared ESLint packages. I prefer a root config plus overrides for apps that need looser rules, until a package truly needs its own toolchain.

Decision criteria for a pilot

Pilot Biome when:

1. ESLint wall time is a real complaint (measured, not gut feel).
2. Your critical rules are in Biome’s covered set or you accept a temporary dual-lint window.
3. You can staff editor + CI cutover in the same week (split cutovers confuse everyone).

Wait when:

1. You rely on custom ESLint rules nobody has ported.
2. You are mid-incident or mid-release freeze (see the migration post for cutover timing).
3. The team’s pain is rule quality, not runtime: Biome will not invent taste.

Axes I write on the pilot issue

Before the first merge, I want five lines in the tracking issue, not a slide:

1. Speed: wall clock for eslint + prettier --check vs biome check on the same package and runner class on the same machine.
2. Unify: one config / one CI step vs two, including pre-commit.
3. Coverage: inventory of must-keep rules and gaps.
4. Migration cost: suppressions, editor rollout, ignore files.
5. Escape hatch: Biome-only vs thin ESLint allowlist with a sunset date.

If you cannot fill those in, you are not ready to migrate, you are ready to read blog posts. The migration post turns the axes into partial vs big-bang judgment.

Failure modes

Rushing the cutover. "One tool to rule them all" is a catchy title, not a migration plan. Dual-running without an exit criteria becomes permanent tax.

Formatting formatting debates in the first PR. Match existing Prettier output as closely as possible (indentStyle, quotes, width) so the first Biome PR is about tooling, not tabs theology. You already picked tabs in the February Prettier package, keep that contract.

Ignoring oxlint. The broader linting thread continues into 2026 (oxlint / oxfmt on the calendar). Biome vs oxlint is a later comparison post. I scope this to one pilot question: is Biome worth trying against ESLint + Prettier?

Continuity

ESLint + Prettier and performance profiling are the baseline. This post is the Biome first look; the migration post covers partial vs big-bang cutover.

Takeaway

Biome earns a pilot when measured lint time and rule coverage line up, not when "one tool" sounds cleaner than a working ESLint + Prettier contract.