Biome is a very interesting project, it is written in Rust and is 97% compatible with prettier. But it goes beyond that and has a linter built in as well that can compete with ESLint. Making it easier to set up and manage while at the same time running 10x faster. This sounds too good to be true. Let’s set it up and see what we can learn from migrating from ESLint/Prettier to Biome.

Setting Up Biome

To get started with Biome, install it via npm:

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

This creates a biome.json configuration file.

Migrate your existing ESLint and Prettier

If you’re already using ESLint and Prettier, migrating is simple:

npx biome migrate eslint --write
npx biome migrate prettier --write

Install the VSCode Plugin

For a seamless experience, install the Biome extension in VSCode. This provides features like automatic fixes and the ability to suppress warnings.

Using Biome

Biome offers flexibility—you decide what to run:

//Formatting
npx biome format --write

//Linting
npx biome lint --write

//Formatting + Linting
npx biome check --write

Without the --write flag, you can preview changes before applying them, which is handy when deciding whether to fully replace ESLint.

Real-World Takeaways

After testing Biome on a larger codebase, here are some key takeaways:

Minor Adjustments

Biome’s default formatting differs slightly from ESLint + Prettier, and it processes all directories by default. A few tweaks helped maintain our existing style:

{
	"files": {
		"ignore": ["dist"] //ignores the output dir
	},
	"javascript": {
		"formatter": {
			"quoteStyle": "double",
			"semicolons":"always
		}
	}
}

Unexpected Surprises

Running biome check uncovered several empty-block functions—something we would normally flag with a //TODO: not implemented comment. Had this gone to QA, it could have led to unnecessary paperwork.

Most issues could be solved by running the command:

npx biome check --write

The Eslint-Ecosystem

While Biome supports many popular ESLint rules, it doesn’t cover everything, especially third-party plugins. The list of supported rules is growing, but it’s not a perfect one-to-one match.

Personally I do not see it as a big problem as eslint rules always are mostly a matter of taste and personal opinion. If a. couple of rules cannot be enforced, well so be it. Since the default ruleset of Biome is anyway larger than the default eslint ruleset - it anyway a step forward.

The \\eslint-disable Problem

Quick // eslint-disable comments are a developer’s best friend (and worst enemy). Biome ignores them, revealing just how many rule suppressions were hidden in our code.

This is a very interesting problem. As using eslint-disable is anyway usually just a temporary measure. Biome offers its own comment to disable a rule… but maybe this time we will just spend the time and remove the technical debt and improve these unstable code paths. Or if you think the rule does not make sense, maybe disable it.

More details on Biome’s linter can be found here.

Future of Biome

For Biome 2.0 The team is working on plugin support. So that is great as it would open up that it actually eventually would support everything that ESLint currently support.

It also looks like that they will support many other things, you can read up on the Roadmap here

Conclusion

Biome is a no-brainer as a Prettier replacement. As a linter, it’s promising—especially for React projects, which it fully supports today. You will notice a significant speed increase compared to using prettier and ESLint.

When you are migrating an existing project you should be aware that you probably will spend a little bit of extra time to clean up the accumulated tech debt. Overall Biome is a great replacement and will greatly increase the code quality of many projects.

Looking ahead to the future, I expect a significant number of projects to make the switch to Biome.