Biome: one Rust binary for JavaScript formatting and linting

The problem Biome targets: two tools, two configs, two passes over the same files

A typical JavaScript project installs Prettier for formatting and ESLint for linting. They are separate processes, separate configuration files, and separate plugin ecosystems. Both parse the same source, and neither knows what the other decided. Biome's stated goal is to unify those functions on a shared base, which the README describes as providing "a cohesive experience for processing code, displaying errors, parallelize work, caching, and configuration." The intended audience is web developers working in JavaScript, TypeScript, JSX, JSON, CSS and GraphQL. The practical appeal is narrower than the slogan: one dependency, one config file, one command that both formats and lints. Biome is written in Rust, and the README notes it does not require Node.js to function, so the binary runs in environments where installing a Node runtime is inconvenient. The project is not archived and the last push was on 2026-08-27, with @biomejs/[email protected] released the same day.

How the formatter, linter and LSP share one parse

The repository is a Cargo workspace. Cargo.toml lists members under crates/ plus several xtask crates used for code generation, and the workspace dependencies enumerate crates such as biome_analyze, biome_css_parser, biome_css_formatter and biome_configuration. That layout reflects the design: each language has its own parser, formatter and analyzer crate, and the CLI and language server sit on top. The README states the parser represents source text "in full fidelity" with error recovery, which is what lets the editor integration format and lint malformed code while it is being typed. The same parser output feeds the formatter and the lint rules, so a file is parsed once per pass rather than once per tool. The LSP is described as first-class, with first-party extensions published on the Visual Studio Marketplace and Open VSX. Configuration is generated rather than hand-written: the justfile contains targets such as gen-schema and gen-types that run xtask_codegen to produce the JSON Schema and TypeScript types for the configuration.

Installing Biome and running a first check

The README gives a single npm command for installation, pinned exactly with --save-exact. Run it in the project root:

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

The README also points to a manual installation guide for setups that do not want Node.js involved, and to an online playground compiled to WebAssembly for trying Biome without installing anything.

With the package installed, the README shows four commands. The broadest is check, which runs formatting, linting and other checks together and applies safe fixes:

npx @biomejs/biome check --write

After it finishes you get a list of diagnostics and the modified files. For CI, where nothing should be written, the README gives a separate command that exits non-zero on violations:

npx @biomejs/biome ci

If you only want one half of the toolchain, format --write and lint --write run them independently. Biome has defaults and does not require configuration, so a first run works without a biome.json; you add one when you need to change rule levels or file selection.

Where Biome is the wrong tool

The README states the formatter scores 97% compatibility with Prettier. That number is a claim about the project's own benchmark, and the missing 3% is the part that matters: on some files Biome will produce output that differs from Prettier. If your repository has committed Prettier output and reviewers treat formatting diffs as noise, adopting Biome means accepting a one-time reformat and any future divergence. The linter side has a comparable boundary. Biome implements more than 500 rules drawn from ESLint, typescript-eslint and other sources, but rules that live in third-party ESLint plugins are a different matter. A project whose lint configuration is mostly plugin rules, especially custom in-house ones, cannot assume a one-to-one mapping. Biome also does not cover every language a web project may contain; the README lists JavaScript, TypeScript, JSX, JSON, CSS and GraphQL, and says the project aims to support all main languages of modern web development, which is an aim rather than a statement of current coverage. Finally, the README does not document a rollback path for a reformat, so plan the change as a reviewable commit rather than something to undo later.

Biome versus ESLint plus Prettier: same job, different architecture

The obvious alternative is the combination most projects already run: ESLint for linting and Prettier for formatting. The difference is architectural rather than cosmetic. ESLint and Prettier are two Node processes, each with its own parser and its own configuration surface, and ESLint's rule set is extended through plugins published independently of the core. Biome is a single Rust binary with one parser per language, one configuration file, and rules that ship with the tool. That means no plugin resolution step and no version drift between a plugin and the parser it depends on. It also means extension is not the same: with ESLint you can write a custom rule and publish it, while Biome's rule set comes from the project itself. Performance is the other axis the README emphasizes, linking to a benchmark repository for both formatting and linting; those numbers come from the project's own harness, so treat them as a starting point for your own measurement rather than a settled comparison. Choose ESLint plus Prettier when plugin coverage or exact Prettier output is a hard requirement. Choose Biome when the rule set covers your needs and you would rather maintain one tool.

Maintenance cost, release cadence and licensing

The repository is not archived and the last push was on 2026-08-27. Releases are frequent: @biomejs/[email protected], 2.5.10 and 2.5.9 all landed in August 2026, roughly a week apart. A cadence that tight cuts both ways. Fixes arrive quickly, and so do minor version bumps, which is why the README's install command uses --save-exact: pinning the version keeps a formatting or linting change from appearing in an unrelated pull request. Upgrading means reading the changelog and re-running check, because a new rule or a changed default can turn a clean tree dirty. The project uses Changesets, with a version script in package.json that runs changeset version, and the repository carries CHANGELOG.md alongside CHANGELOG_v1.md. On licensing, the README states Biome is MIT licensed or Apache 2.0 licensed, and Cargo.toml declares license = "MIT OR Apache-2.0". That dual arrangement is permissive and is the same pattern used across much of the Rust ecosystem. Whether it fits your organisation's policy is a question for your own review, not something the repository answers.

Building from source and the tooling the project expects

Contributors and anyone packaging Biome themselves work from the Cargo workspace rather than npm. The justfile defines an install-tools recipe that installs cargo-binstall, then uses it for cargo-insta, wasm-opt, cargo-deny and a pinned wasm-bindgen-cli, followed by pnpm install. The workspace pins edition = "2024" and the repository includes rust-toolchain.toml, so the compiler version is fixed by the checkout. package.json requires Node >=22.13 and pnpm 12.3.4 through the packageManager field. Several justfile recipes regenerate checked-in artifacts rather than source: gen-schema and gen-types emit the configuration's JSON Schema and TypeScript types, and gen-rules regenerates files inside the analyzer crates. The comment above gen-all says it is rarely wanted locally, which is a fair warning: running the full generation path rewrites a large number of files and should not be mixed into an unrelated change. For consumers of the npm package none of this matters, but it explains why the repository contains both a Cargo.lock and a pnpm-lock.yaml.

Editorial conclusion

Adopt Biome if your project is plain JavaScript, TypeScript, JSX, JSON, CSS or GraphQL and you want formatting and linting from one binary with a single config file. Do not adopt it if your lint setup depends on ESLint plugins with no Biome equivalent, or if you need Prettier's exact output on every file. Before committing, run npx @biomejs/biome check --write on a branch and inspect the diff, then confirm that the rules you currently rely on are covered by the more than 500 rules the README cites.

Frequently asked questions

Official sources

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