--- title: "Biome vs ESLint + Prettier" slug: "biome-vs-eslint-prettier" category: "comparisons" tags: ["comparisons", "biome", "eslint", "prettier", "linting", "tooling"] status: "stable" last_updated: 2026-05-29 summary: "Pick Biome for new projects wanting lint and format in one tool; pick ESLint plus Prettier when you need deep rule libraries or framework-specific plugins." related: ["[[comparisons/eslint-vs-biome]]", "[[coding/typescript]]", "[[coding/typescript-strict-mode]]", "[[coding/general-principles]]", "[[tooling/github]]", "[[comparisons/vitest-vs-jest]]", "[[file-organization/project-structure]]", "[[file-organization/monorepo]]"] --- ## Overview Pick Biome for any new TypeScript or JavaScript project in 2026 where one tool that lints and formats with a single config is the win. Pick ESLint plus Prettier when the codebase relies on rule plugins Biome does not yet cover (framework-specific, accessibility-deep, custom organizational rules) or when the migration cost outweighs the speedup. The split is concrete: Biome owns "greenfield projects and teams that hate config sprawl"; ESLint plus Prettier owns "established codebases with rule depth and migration risk." This page frames Biome against the full lint-plus-format toolchain; for the narrower linter-vs-linter comparison, see [[comparisons/eslint-vs-biome]]. ## When Biome wins Biome is the right pick when speed, single-binary simplicity, and zero plugin config matter. - One binary, two jobs: `biome lint` and `biome format` cover what ESLint plus Prettier did, with one config file (`biome.json`). The transformer pipeline is shared. - Speed: Biome is written in Rust and runs 10 to 50 times faster than ESLint plus Prettier on the same codebase. A 200k-LoC repo lints in 1 to 2 seconds. - No plugin coordination: no `eslint-config-prettier`, no `eslint-plugin-prettier`, no version-matrix problems between formatter and linter. - Sensible defaults: the rules ship opinionated and aligned with idiomatic TypeScript. Most teams write a 30-line `biome.json` and never touch it again. - Editor integration: official extensions for VS Code, Zed, JetBrains. Fast enough to run on save without delay. - LLM agents pattern-match Biome well: one config, fewer surfaces, predictable output. ## When ESLint plus Prettier wins ESLint plus Prettier is the right pick when the rule ecosystem or the migration cost is decisive. - Plugin depth: `eslint-plugin-react`, `eslint-plugin-jsx-a11y`, `eslint-plugin-import`, `eslint-plugin-jest`, `eslint-plugin-vue`. Biome covers the basics; the long tail still belongs to ESLint. - Custom rules: an org-specific lint rule (no internal `console.error` outside `lib/log`) is a one-file ESLint plugin. Biome supports custom rules via GritQL but the catalog is younger. - Existing investment: a codebase with a 200-line `.eslintrc.js` plus a CI gate is not worth migrating unless lint speed is hurting daily work. - Framework-specific lint: Next.js ships `eslint-config-next`. Nuxt, Astro, and others ship Prettier and ESLint configs. Biome support is catching up but lags. - Accessibility-deep rules: `eslint-plugin-jsx-a11y` has 30+ rules. Biome's a11y rules are present but smaller. See [[frontend/accessibility]] equivalents. - Format-only-with-Prettier users: Prettier's plugin ecosystem (Tailwind class sorting, Astro, Markdown, YAML) is broader than Biome's. ## Trade-offs at a glance | Dimension | Biome | ESLint + Prettier | | ---------------------- | -------------------------------- | ------------------------------------ | | Tools | One binary | Two tools, glue config | | Speed | 10 to 50x faster | Baseline | | Config files | `biome.json` | `.eslintrc`, `.prettierrc`, glue | | Plugin ecosystem | Growing | Largest in 2026 | | Custom rules | GritQL, newer | Mature plugin API | | Framework configs | Smaller catalog | Native for every major framework | | Format support | JS, TS, JSX, JSON, CSS, GraphQL | JS, TS, plus Prettier plugins | | Editor experience | Fast on-save | Acceptable; slower on big files | | Monorepo | Single config or per-package | Per-package configs, glue | | Migration codemod | `biome migrate eslint` | Native | | LLM agent output | Small surface, predictable | Large surface; more idioms to know | | License | Open source (MIT, Apache 2.0) | Open source (MIT) | ## Migration cost ESLint plus Prettier to Biome is mostly automated for greenfield-shaped repos. Established repos with deep rule libraries cost more. - Run `biome migrate eslint` and `biome migrate prettier`. These import rules and format options into `biome.json`. The output covers 80 to 90 percent of typical configs. - Drop `eslint`, `prettier`, `eslint-config-prettier`, `eslint-plugin-prettier` from `package.json`. Remove the per-plugin packages Biome already covers. - Audit remaining ESLint plugins: Biome ships its own hooks rules (`useExhaustiveDependencies`, `useHookAtTopLevel`), but if you need the exact behavior of `eslint-plugin-react-hooks` exhaustive-deps or a custom org plugin, you keep ESLint for that subset. Most teams either drop the plugin or run a tiny ESLint config alongside Biome. - Plan one engineer-day per 50k LoC for a clean repo; one engineer-week for a repo with deep custom rules and CI gates that rely on ESLint output format. - Pre-commit hooks: swap `lint-staged` commands from `eslint --fix` and `prettier --write` to `biome check --apply`. See [[tooling/github]]. ## Recommendation - New TypeScript or JavaScript project in 2026: Biome. - Existing project, team happy, lint speed not painful: stay on ESLint plus Prettier. Migration is not free. - Next.js project that relies on `eslint-config-next`: stay on ESLint until Biome's Next.js story matures, or run both with Biome doing formatting only. - React project with deep a11y lint requirements: ESLint plus `eslint-plugin-jsx-a11y`. Biome covers the basics. - Monorepo with consistent style across many packages: Biome; one config, one binary, fast. - Library author publishing to npm: Biome; smaller dev-dependency footprint for contributors. ## Related - [[comparisons/eslint-vs-biome]] - [[coding/typescript]] - [[coding/typescript-strict-mode]] - [[coding/general-principles]] - [[tooling/github]] - [[comparisons/vitest-vs-jest]] - [[file-organization/monorepo]]