Biome is redefining JavaScript and TypeScript tooling by replacing ESLint and Prettier with a single, dramatically faster tool written in Rust. Launched in 2024 as a fork of Rome, Biome provides formatting, linting, and import organisation in a unified toolchain that runs 10–100× faster than the JavaScript-based tools it replaces. For engineering teams spending significant CI time on lint and format checks, and dealing with configuration complexity across multiple tools, Biome offers a compelling consolidation path.
What Is Biome and What Problem Does It Solve?
Modern JavaScript/TypeScript projects typically chain multiple tools for code quality: ESLint for linting with 10–50 plugins, Prettier for formatting, and often separate import ordering plugins. Each tool has its own configuration, runs separately in CI, and can produce conflicting rules that require careful configuration to reconcile. The combined configuration surface is substantial — a typical .eslintrc.json, .prettierrc, and associated plugin configurations may span hundreds of lines with non-obvious interactions.
Biome replaces this stack with a single Rust binary and a single biome.json configuration file. It performs formatting (Prettier-compatible output by default), linting (290+ rules across JavaScript, TypeScript, JSX, CSS, and JSON), and import organisation. Its Rust implementation and single-pass architecture produce execution times measured in milliseconds for entire large codebases — formatting 97,000 JavaScript files in 0.8 seconds in official benchmarks.
Migration from ESLint + Prettier to Biome
Biome's migration tooling makes the transition manageable even for large codebases. The biome migrate command analyses existing ESLint and Prettier configurations and generates an equivalent biome.json, flagging rules without Biome equivalents for manual review. The migration process is typically completed in a day for medium-size projects.
Step 1 — Run biome migrate: Execute npx @biomejs/biome migrate eslint --write and npx @biomejs/biome migrate prettier --write to generate initial biome.json from existing configurations. Review the migration report for rules that couldn't be mapped.
Step 2 — Run initial check: Execute biome check --write ./src to apply formatting and auto-fix linting issues. The first run typically produces a large diff — commit it as a dedicated "adopt Biome" commit to keep it separate from functional changes for easier code review history.
Step 3 — Address unmapped rules: Review ESLint rules without Biome equivalents. Most are covered by Biome's rule set under different names; genuinely missing rules may require keeping a minimal ESLint configuration for those specific checks or accepting the gap if the rules are low-priority.
Step 4 — Update CI pipeline: Replace ESLint and Prettier CI steps with biome ci (the CI-specific command that errors on any formatting or linting issues without making changes). A single biome ci command replaces multiple separate tool invocations.
| Capability | Biome | ESLint + Prettier | Notes |
|---|---|---|---|
| Formatting | ✅ Built-in | Prettier (separate) | 97% Prettier-compatible output |
| Linting | ✅ 290+ rules | ESLint + plugins | Most common rules covered |
| Import organisation | ✅ Built-in | Via eslint-plugin-import | Configurable sort order |
| TypeScript support | ✅ Native | Via @typescript-eslint | No separate parser needed |
| Performance | 25–100× faster | Baseline | Most impactful on large repos |
| Plugin ecosystem | Growing (limited) | Very large | Main trade-off vs ESLint |
| Config complexity | Single biome.json | Multiple config files | Biome significantly simpler |
Limitations and When to Keep ESLint
Biome's main limitation is ecosystem breadth. ESLint's plugin ecosystem is vast — dedicated plugins for React hooks rules, accessibility (jsx-a11y), security patterns, testing library conventions, and dozens of framework-specific rule sets exist because they were built over years by the community. Biome's plugin system is newer and fewer community rules exist outside the built-in set.
The practical implication: if your ESLint configuration relies heavily on specialised plugins (jsx-a11y for accessibility enforcement, eslint-plugin-security for security rules, framework-specific plugins), migrating to Biome means either accepting reduced rule coverage in those areas or maintaining a parallel minimal ESLint configuration for the specialised rules. This hybrid approach — Biome for formatting and general linting, ESLint only for specialised rules — is a viable migration path for teams that cannot immediately remove all ESLint dependencies.
The recommendation: evaluate Biome for new projects as the default toolchain. For existing projects, migrate opportunistically when the configuration complexity of the current ESLint + Prettier setup is causing pain, with a careful audit of which ESLint rules you actually rely on versus which are installed but rarely triggered.