Skip to content

Trying Out Biome: One Tool to Rule Them All?

I’ve written a lot recently about configuring ESLint and Prettier, dealing with pre-commit hooks, and optimizing slow rules.

3 min read
Biome
ESLint
Prettier
Linting
Formatting
Tooling

I’ve written a lot recently about configuring ESLint and Prettier, dealing with pre-commit hooks, and optimizing slow rules. But lately, one name keeps popping up on my radar: Biome. As of late 2025, Biome is stable enough that the question "Should we actually switch?" is becoming real, especially for teams that are already comfortable with the ESLint and Prettier ecosystem.

To be honest, the "all-in-one" concept is tempting. Usually, using ESLint and Prettier means juggling two different tools, two config files, and the endless debate over which one actually owns your code formatting. Biome arrives as a single Rust-based binary that handles both the formatter and the linter.

The benefits make sense to me. First, CI becomes much simpler; you don't have to run prettier --check and then follow it up with eslint separately. Second, there's the speed. If you feel like linting in a large project is starting to drag, Biome’s Rust-based engine might be the answer. Most importantly, it cuts out the headache of resolving formatting conflicts between Prettier and ESLint that we usually have to disable manually.

But Biome has its downsides too. Even though its rules are growing, it can't replicate every single plugin we might already be using in ESLint—like specific React Hooks discipline or very niche import rules. If your company relies on custom rules written in JavaScript, ESLint still feels much more flexible.

If I were to start using it, I wouldn't just scrap ESLint on day one. A better approach would be to run Biome in "shadow mode." Let it run in your CI to report linting and formatting results, but don't let it fail the build yet. Watch how it compares to ESLint for a couple of weeks. If everything looks good, then you make the call.

I also anticipate a few hiccups when first touching Biome. The configuration model is different, so don't just copy-paste your ESLint settings. Then there's the editor setup, which is crucial. A lot of people complain that Biome is broken, but the real issue is often that they forgot to turn off Prettier's "format-on-save." When that happens, the two tools just end up fighting inside your editor.

So, when should you actually start a pilot project with Biome? Maybe when the complaints about slow linting become a real problem (not just a feeling), or if your core rules are already supported. But don't rush into it if your team is heavily dependent on custom rules that haven't migrated to Biome yet.

Not everything needs to be replaced just because a new, faster tool exists. We have to see if it actually solves a problem or just adds a new layer of configuration cost.

Stopping here.