Biome 2.5: One Rust binary to replace Prettier and ESLint

What Biome solves and who it targets

Biome addresses a familiar pain: web projects that need both formatting and linting but have to install, configure, and run two separate tools. Prettier handles formatting, ESLint handles rules, and each has its own config file, CLI flags, and editor plugin. Biome replaces that pair with one binary that does both. The README positions it as a toolchain for web projects, aimed at maintaining project health. The target user is a developer or team working with JavaScript, TypeScript, JSX, JSON, CSS, or GraphQL who wants a single tool with sane defaults and no mandatory configuration. The pitch is performance, but the deeper value is unification: one shared base for parsing, diagnostics, caching, and parallelization. That is a real architectural difference, not just a speed claim.

The mechanism: full-fidelity parser and shared core

Biome's design centers on a sophisticated parser that represents source text in full fidelity and has top-notch error recovery. Full fidelity means the parser preserves every token and comment, which is essential for a formatter that must round-trip code without losing information. Error recovery lets it format and lint malformed code, which is why the editor experience works on partially written files. The README says Biome is designed from the start to be used interactively within an editor, with first-class LSP support. The shared base matters: formatting, linting, and diagnostics all run on the same parse tree, so there is no duplicated work. Caching and parallelization are also built into that shared core. That is a different approach from running Prettier and ESLint separately, where each tool parses the file independently.

Getting it running: install and basic commands

Installation is a single npm command: npm install --save-dev --save-exact @biomejs/biome. The README does not mention a version, but the latest release listed is v2.5.11. The --save-exact flag is notable: Biome recommends pinning the exact version, which is common for tools that change behavior between releases. After install, you run it via npx. The README gives four commands. Format files with npx @biomejs/biome format --write. Lint and apply safe fixes with npx @biomejs/biome lint --write. Run both and apply safe fixes with npx @biomejs/biome check --write. For CI, use npx @biomejs/biome ci, which the README describes as checking all files against format, lint, etc. without writing changes. There is also an online playground compiled to WebAssembly, so you can try it without installing anything.

Compatibility claims: Prettier and ESLint coverage

Biome makes two concrete compatibility claims. First, it scores 97% compatibility with Prettier, according to a benchmark linked in the README. That is a high number, but it also means 3% of formatting cases will differ. For a team that has existing Prettier-formatted code, that 3% can cause noisy diffs on migration. Second, it features more than 500 lint rules sourced from ESLint, typescript-eslint, and other sources. The README does not say all ESLint rules are included, only that it has more than 500 from those sources. That is a useful baseline, but custom ESLint plugins or rules that you wrote yourself will not be available unless they are ported. The rule count is a feature, but it is not a guarantee of parity. You need to check the actual rule list against your project's ESLint config.

A real limitation: configuration and rule gaps

The README states that Biome has sane defaults and does not require configuration. That is a strength for new projects, but it is also a limitation. Prettier and ESLint are highly configurable; teams often have specific formatting rules or custom lint rules. Biome's defaults are opinionated. If your project relies on a non-default Prettier setting, such as a different print width or semicolon style, you will need to find the corresponding Biome configuration option, and it may not exist. The README does not document configuration keys, so you must consult the official documentation to see what is tunable. Another limitation is the rule source. With 500+ rules from ESLint and typescript-eslint, you may find that a niche rule you depend on is missing. The README does not provide a migration tool. You will have to manually map your ESLint config to Biome's rules. For a large codebase, that is a real cost.

Alternatives: Prettier plus ESLint, or other Rust tools

The obvious alternative is to stick with Prettier for formatting and ESLint for linting. That combination is mature, has a huge plugin ecosystem, and is what most web projects use today. The difference in approach is that Prettier and ESLint are separate tools, each with its own parser, config, and editor integration. Biome unifies them, which reduces toolchain complexity and duplicate parsing. Another alternative is other Rust-based tools, such as Ruff for Python or oxc, but the README does not mention them. In the web space, you could also use deno lint or deno fmt, which also combine formatting and linting, but those are tied to the Deno runtime. Biome stands out because it is runtime-agnostic and does not require Node.js, as the README notes. The trade-off is that you trade the flexibility of separate tools for the speed and cohesion of a single binary.

Maintenance, licensing, and upgrade cost

The repository is under the Apache-2.0 license, and the README also mentions it is MIT licensed or Apache 2.0 licensed, with a dual-license approach. That is permissive, so you can adopt it without legal friction, but you should read the license files to confirm which applies to your use. The project is actively maintained, with releases on a roughly weekly basis: 2.5.9 on August 17, 2.5.10 on August 21, and 2.5.11 on August 27, 2026. That cadence means you will need to track updates and test your codebase against new versions. The --save-exact recommendation in the install command suggests that upgrades can introduce breaking changes. The README does not describe a migration path from Prettier or ESLint, so you should plan for manual configuration mapping and a formatting diff review. The LSP support means your editor will need to be reconfigured to use Biome instead of the existing extensions.

Editorial conclusion

Adopt Biome if you manage a JavaScript or TypeScript project and want a single, fast formatter and linter with editor integration, and you are willing to accept its default configuration and rule set. Avoid it if you depend on a large ESLint plugin ecosystem or need Prettier's exact output for every edge case. Before switching, verify that Biome's formatting matches your codebase's expectations and that its lint rules cover the specific checks you rely on, especially if you use custom ESLint rules or plugins not ported to Biome.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes