Replacing ESLint and Prettier with Biome: Field Notes from Two Production Repos

Key takeaways

Biome replaces both ESLint and Prettier with a single Rust binary, one configuration file (biome.json), and one command — biome check --write — that formats, lints, and organizes imports in a single pass.

The migration is mostly automated: biome migrate eslint --write and biome migrate prettier --write translate your existing configuration, but rules that depend on ESLint plugins do not carry over automatically.

Biome 2.0 introduced type-aware lint rules that run without invoking the TypeScript compiler, so a rule such as noFloatingPromises works without wiring up tsc.

The headline benefit is speed: one Rust binary runs formatting, linting, and import sorting in parallel, finishing large repositories in a fraction of the time an ESLint plus Prettier pipeline takes.

Biome is not a complete ESLint replacement yet; its plugin ecosystem is young, so teams that depend on specific plugins often run Biome and ESLint side by side.

What does Biome replace?

Biome is a single toolchain that combines a formatter — a near-drop-in Prettier replacement — and a linter — an ESLint-style rule engine — in one Rust binary. In a typical project it stands in for four moving parts at once: Prettier, ESLint, the eslint-config-prettier glue that stops them from formatting-fighting, and a separate import-sorting plugin. Everything lives in one biome.json, and a single command, biome check --write, formats the code, applies safe lint fixes, and sorts imports together and deterministically.

When should a team switch to Biome?

Switch when your linting stack has become its own maintenance burden and you are not relying on niche ESLint plugins. The concrete signals: lint and format slow enough to notice in a pre-commit hook or in CI; an ESLint config that has drifted into flat-config plus a stack of plugins nobody fully understands; mostly standard rules rather than a large set of custom ones; and wanting type-aware rules without paying the full type-check cost on every run.

How do we migrate an ESLint and Prettier setup?

Biome ships migration commands that read your existing configuration and translate it. After installing @biomejs/biome as an exact dev dependency, run biome migrate eslint --write and biome migrate prettier --write. The ESLint migration maps rules with Biome equivalents into biome.json and preserves overrides; the Prettier migration copies your options — quote style, semicolons, trailing commas, print width — so formatting stays visually identical. Rules from a plugin without a Biome counterpart are simply dropped, so diff the generated config against your old rule list and make a deliberate call on each gap. Then delete ESLint, Prettier, and eslint-config-prettier and re-point the pre-commit hook and editor at Biome.

What does Biome 2.0 type-aware linting change?

Biome 2.0 introduced type-aware lint rules that run without invoking the TypeScript compiler. In the ESLint world, rules that reason about types require typescript-eslint with type information, which means running the TypeScript type-checker as part of linting — usually the slowest part of a lint run. Biome performs its own lightweight type inference in Rust, so a rule such as noFloatingPromises works out of the box without a type-check pass. It is not a full type-checker and will not replace tsc for build-time type safety, but for the type-aware rules it covers it is far cheaper to run.

How does Biome work in a monorepo?

Biome 2.0 supports nested configuration for monorepos: a root biome.json defines shared defaults, and each package extends it and overrides rules locally by setting extends to the root marker "//". This keeps one shared formatting and lint baseline while letting an API package be stricter about stray console.log calls than the frontend package, without duplicating the whole config.

Biome compared with ESLint and Prettier

Moving parts: ESLint plus Prettier is two tools, two configs, and a glue package; Biome is one binary and one biome.json. Implementation: ESLint and Prettier are JavaScript; Biome is Rust.

Performance and features: an ESLint plus Prettier pipeline takes several seconds on a large repo, while Biome typically finishes in under a second, with import sorting built in and type-aware rules that need no tsc. In exchange, ESLint's plugin ecosystem is far more mature with thousands of plugins, while Biome's GritQL-based plugin system is still young. Formatting is near-Prettier parity with only minor differences.

What still keeps us on ESLint?

Biome's rule set does not yet match every rule from popular plugins such as eslint-plugin-jsx-a11y or eslint-plugin-import, and its GritQL plugin story is far younger than ESLint's thousands of community plugins. On one repo with strict accessibility rules and a couple of custom organization-specific rules, we kept a slim ESLint config for exactly those and let Biome own formatting, import sorting, and the bulk of correctness linting. Running both is not free, but scoping ESLint down to the handful of rules Biome cannot express still removed most of the old overhead.

FAQ

**Q:** Is Biome a drop-in replacement for Prettier?

**A:** For formatting it is near-drop-in — Biome targets high Prettier compatibility, and after migrating you will see only a handful of edge-case differences. Its options map directly to Prettier's: quote style, semicolons, trailing commas, and print width.

**Q:** Does Biome need the TypeScript compiler for type-aware rules?

**A:** No. Since Biome 2.0, type-aware rules such as noFloatingPromises run on Biome's own type inference without invoking tsc, so linting stays fast. Biome does not replace tsc for full build-time type checking.

**Q:** Can we run Biome and ESLint at the same time?

**A:** Yes, and it is a common transitional setup. Let Biome handle formatting, import sorting, and standard lint rules, and keep a scoped ESLint config only for plugin rules Biome has no equivalent for, such as specific accessibility or import-resolution checks.

**Q:** Which languages does Biome support?

**A:** Biome formats and lints JavaScript, TypeScript, JSX/TSX, JSON, and CSS, with GraphQL support and more languages progressing. Markdown and YAML formatting are still maturing, so check the current support matrix before relying on them.