Blog
3 min read

Biome vs ESLint + Prettier: Should You Switch?

Biome is a single Rust-based tool that formats and lints JavaScript, TypeScript, JSON and CSS — much faster than ESLint plus Prettier, with one config file. How they compare on speed, rule coverage, plugins, type-aware linting and framework support, how to migrate, and when to stay with ESLint.

For years the default JavaScript setup was ESLint for finding problems plus Prettier for formatting — two tools, two configs, a plugin to stop them fighting. Biome offers both in one fast binary. (Linters and Formatters Explained)

The short version

  • Switch to Biome if you want speed and simplicity, and your project doesn't depend on niche ESLint plugins.
  • Stay with ESLint + Prettier if you rely on framework-specific or company plugins, or deep type-aware rules from typescript-eslint.

Side by side

Biome ESLint + Prettier
Written in Rust JavaScript
Tools One (format + lint + import sorting) Two (plus glue)
Speed Very fast — often 10x+ on big repos Slower, especially type-aware linting
Config One biome.json eslint.config.js + .prettierrc
Languages JS, TS, JSX, JSON, CSS, GraphQL, more Anything with a plugin
Rules Hundreds built in, many ported from ESLint plugins Huge ecosystem of plugins
Custom rules Plugins (GritQL patterns) Full JS plugin API
Type-aware linting Some rules, without running tsc Full, via typescript-eslint (slower)

Getting started with Biome

npm install --save-dev --save-exact @biomejs/biome
npx @biomejs/biome init

That creates biome.json. Then:

npx biome format --write .   # format
npx biome lint .             # lint
npx biome check --write .    # format + lint + organise imports, applying safe fixes

Use biome ci in your CI pipeline. Install the Biome extension for VS Code (or your editor) and set it as the default formatter. (GitHub Actions CI Basics)

Migrating from ESLint and Prettier

Biome can read your existing configs:

npx biome migrate eslint --write
npx biome migrate prettier --write

It maps the rules it knows and reports the ones it doesn't. Then:

  1. Run biome check --write once and commit the formatting changes as a separate commit, so real changes stay readable in history. (Write Good Commit Messages)
  2. Remove ESLint, Prettier and their plugins from package.json.
  3. Update editor settings, pre-commit hooks and CI.

Biome's formatter aims for Prettier compatibility, so the diff is usually small.

Where ESLint still wins

  • Plugin coverage. Rules for specific frameworks, testing libraries, accessibility (Biome has many a11y rules, but not everything), and in-house conventions.
  • Fully type-aware rules like "no floating promises" across your whole program, which typescript-eslint does by running the TypeScript compiler.
  • Framework defaults. Some frameworks ship ESLint configs and expect them; you can still use Biome, but you'll configure more yourself.

A hybrid is common: Biome for formatting and most linting, ESLint only for the handful of plugin rules you can't replace.

Why speed matters more with AI coding

Coding agents run the linter after every change. A check that takes 200 ms instead of 20 seconds means the agent gets feedback immediately and fixes issues in the same turn. Fast tools make Claude Code hooks that format on every edit practical.

The summary

  • Biome = formatter + linter in one fast tool with one config.
  • Migrate with biome migrate eslint / prettier, and commit formatting separately.
  • Keep ESLint if you depend on plugins or full type-aware rules — or run both.

EasySpawn gives Claude Code a persistent workspace where your formatter and linter run on every edit, so code arrives at review already clean. See how it works or join the waitlist.

Related: Refactor AI-Generated Code · TypeScript for AI-Generated Code · Vitest vs Jest · Technical Debt in AI-Built Apps

Keep reading