I Replaced ESLint and Prettier with Biome on Two Production Repos

Headline: Biome is a single Rust-based toolchain that formats and lints JavaScript and TypeScript in one pass, replacing the ESLint + Prettier pair. On two production repos it collapsed two configs, two dependency trees, and two editor plugins into one binary — and turned the lint-and-format step from several seconds into well under a second. It does not yet cover every ESLint plugin, so here is where it won and where I kept ESLint.

For years my default JS setup was ESLint for correctness, Prettier for formatting, eslint-config-prettier to keep them from arguing, and an import-sorting plugin. It works, but it is four dependencies, two configs, two editor extensions, and a pre-commit hook running two tools. Biome — one Rust binary that does both — has matured enough that I migrated two production repos to it. These are the field notes.

Key takeaways

• Biome replaces both ESLint and Prettier with one binary, one config (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 configs, but plugin-specific rules do not carry over.
• Biome 2.0 added type-aware lint rules that run without the TypeScript compiler, so noFloatingPromises works without wiring up tsc.
• Speed is the headline win: one Rust binary runs format, lint, and import sorting in parallel, finishing a large repo in a fraction of the time ESLint + Prettier takes.
• It is not a complete ESLint replacement yet: the plugin ecosystem is young, so you may run Biome and ESLint side by side.

What does Biome actually replace?

Biome is a single toolchain combining a formatter (a near-drop-in Prettier replacement) and a linter (an ESLint-style rule engine) in one Rust binary. It stands in for four parts at once: Prettier, ESLint, the eslint-config-prettier glue, and a separate import-sorting plugin. One biome.json holds formatter options, lint rules, and import organization, and one command does the whole job:

# format, lint, and organize imports in a single pass
biome check --write .

When should I switch from ESLint and Prettier to Biome?

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

How do I migrate an existing ESLint + Prettier setup?

npm i -D --save-exact @biomejs/biome
npx biome migrate eslint --write
npx biome migrate prettier --write

biome migrate eslint maps ESLint rules with Biome equivalents into biome.json; biome migrate prettier copies your Prettier options so formatting stays visually identical. Rules from plugins without a Biome counterpart are dropped, so diff the generated config against your old rule list and make a 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's type-aware linting change?

Biome 2.0 introduced type-aware lint rules that run without invoking the TypeScript compiler. ESLint rules that reason about types need typescript-eslint with type information, which runs tsc as part of linting — usually the slowest part. Biome does its own lightweight type inference in Rust, so noFloatingPromises works without a type-check pass. It 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 config: a root biome.json defines shared defaults, and each package extends it and overrides locally with "extends": "//":

// packages/api/biome.json
{
  "extends": "//",
  "linter": {
    "rules": {
      "suspicious": { "noConsole": "error" }
    }
  }
}

Biome vs ESLint + Prettier at a glance

Dimension	ESLint + Prettier	Biome
Moving parts	Two tools, two configs, a glue package	One binary, one biome.json
Implementation	JavaScript	Rust
Speed on a large repo	Several seconds	Typically sub-second
Import sorting	Separate plugin	Built in
Type-aware rules	Need typescript-eslint + tsc	Built-in inference, no tsc
Plugin ecosystem	Thousands of mature plugins	Young (GritQL plugins)
Formatting	Prettier	Near-Prettier parity

What still keeps me on ESLint?

Biome's rule set does not yet match every rule from plugins like eslint-plugin-jsx-a11y or eslint-plugin-import, and its GritQL plugin story is far younger than ESLint's ecosystem. On one repo with strict accessibility rules and a couple of custom org-specific rules, I kept a slim ESLint config for exactly those and let Biome own formatting, import sorting, and the bulk of correctness linting. Scoping ESLint down to the few 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 you will see only a handful of edge-case differences after migrating.

Q: Does Biome need the TypeScript compiler for type-aware rules?
A: No. Since Biome 2.0, rules like noFloatingPromises run on Biome's own inference without tsc. Biome does not replace tsc for full type checking.

Q: Can I run Biome and ESLint at the same time?
A: Yes — a common transitional setup. Let Biome handle formatting, imports, and standard rules, and keep a scoped ESLint config only for plugin rules Biome has no equivalent for.

Q: Which languages does Biome support?
A: JavaScript, TypeScript, JSX/TSX, JSON, and CSS, with GraphQL support and more progressing. Markdown and YAML formatting are still maturing.

Q: How do I migrate without hand-writing a config?
A: Install @biomejs/biome, then run biome migrate eslint --write and biome migrate prettier --write. Review the generated biome.json, since rules from unsupported plugins are dropped.

---

Originally published on devya.dev. Also on eng-ahmed.com. Built by Devya Solutions.