biomejs/biome

Reasonable pick if your JavaScript/TypeScript project lives with a pile of separate lint and format configs and you want one tool to do the boring work. It is not a drop-in replacement for every rule set you already depend on, so check your existing lint config first.

The problem

A typical web project arrives with ESLint plus several plugins, Prettier, and separate JSON and CSS formatters, each with its own config file and its own editor integration. Running them in sequence means duplicate traversals of the same files, conflicting rules, and a CI step that has to invoke several binaries. Biome bundles formatting and linting for JavaScript, TypeScript, JSX, JSON and CSS into one command and one LSP server, so a developer can run check --write locally, and CI can run ci to enforce the same rules. The project says it works without Node.js and doesn't require configuration.

What's different

The implementation is in Rust with a full-fidelity parser and LSP support, and the README presents that as the basis for both speed and diagnostic quality. Installing an npm package gives you a native binary, an editor integration through the VS Code or Open VSX extension, and a CLI covering format, lint and check in one pass over a project. The playable form for evaluation is an online playground compiled to WebAssembly, which makes trying a rule change cheap before touching the repository.

The trade-off is config compatibility. The selling point is "sane defaults and it doesn't require configuration," which works best for greenfield projects or teams willing to adopt Biome's rule set. If your codebase depends on a long list of ESLint plugins and custom rules, you need to audit what carries over before switching. The plugin story is still a design question: in the January 2024 RFC thread, a commenter describing the project said the main options being discussed were JS/TS plugins, possibly via Deno crates, and WASM, and they asked for input on the plugin system. Even a plugin path would not automatically preserve existing ESLint semantics.

Who should try it

Good fit: a team starting a TypeScript or JavaScript project that wants formatting and linting from one binary with minimal setup, or a developer who wants a fast check step in CI with the editor applying the same rules through the LSP. It also suits people working on CSS and JSON in the same repo, since a single toolchain covers those files. Poor fit: a project whose lint behavior depends on specific ESLint plugins, because the documented design centers on Biome's own rules rather than extending an existing ESLint setup. A team that needs a mature third-party plugin API before adopting will also want to watch how that RFC resolves rather than assume it's done.

Requirements and limitations

Installation is via the npm package (with manual installation documented as an alternative that doesn't need Node.js), so the usual package manager path works for most web developers. The editor experience depends on the VS Code or Open VSX extension for first-class LSP support, though the CLI still covers formatting and linting if you don't use those editors. The remaining deep limitation is coverage of existing ESLint rules and plugins: migrating means checking which diagnostics you'll lose or must reconfigure. Adopting "no config" defaults also means the first run may reformat or flag files differently from your previous setup, so plan the switch as a real change rather than a silent swap.

HotRepo's take

HotRepo tracks the project from 2026-10-24 and records it once on the daily board, on 2026-10-25 with 25,993 stars and +8 that day. A single observation can't establish whether interest is rising or fading, so persistence isn't judgeable from this sample. The 2024 HN RFC thread (1 point) shows an early design discussion, not current adoption evidence. Before committing, verify how the project's language support and rule coverage line up with the ESLint rules your codebase actually relies on.