Y
our team has three linting configs, two Prettier files, and a.eslintignore nobody remembers writing. Every PR has at least one comment about formatting. CI fails on a missing semicolon that VSCode didn't catch because someone's extension is a version behind.
Biome fixes this. Not by being clever by being fast, opinionated, and single-file configured. Here's how to get it running in VSCode so format-on-save actually works, and how to avoid the one mistake that trips up almost every team doing this for the first time.
What Biome gives you in VSCode
Biome is a linter and formatter for TypeScript (and JavaScript), built in Rust. The VSCode extension integrates directly with the Biome CLI, so what you see in the editor is exactly what runs in CI. No drift. No "works on my machine" formatting fights.
The Go analogy in the title is intentional. Go ships with gofmt. It doesn't ask for opinions. It formats your code, you commit it, done. Biome is that for TypeScript lint on save, format on save, one config file, one tool.
The extension install takes under a minute. Unlike ESLint with 14 plugins, Biome's TypeScript rules ship in the binary no separate installs, no peer dependency hell.
Installing the extension
Open VSCode, go to Extensions, search "Biome". Install the one published by biomejs. That's it.
The extension ID is biomejs.biome. If you prefer the command line:
Untitled1code --install-extension biomejs.biome
The extension does nothing useful without the Biome CLI in your project. Add it:
Untitled1npm install --save-dev @biomejs/biome
Or with Bun, which is faster and what we use on new projects:
Untitled1bun add --dev @biomejs/biome
Then initialise a config:
Untitled1npx biome init
This creates a biome.json at your project root. That file is your single source of truth for everything linting rules, formatting rules, file ignores. Commit it.
Making format-on-save actually work
The extension respects VSCode's editor.formatOnSave setting, but you need to tell VSCode to use Biome as the default formatter for TypeScript files. Otherwise it'll keep using Prettier, or nothing, which is worse.
Add this to your .vscode/settings.json:
Untitled1{2 "editor.defaultFormatter": "biomejs.biome",3 "editor.formatOnSave": true,4 "[typescript]": {5 "editor.defaultFormatter": "biomejs.biome"6 },7 "[typescriptreact]": {8 "editor.defaultFormatter": "biomejs.biome"9 },10 "[javascript]": {11 "editor.defaultFormatter": "biomejs.biome"12 },13 "[json]": {14 "editor.defaultFormatter": "biomejs.biome"15 }16}
Commit this file. Your whole team gets the same behaviour without individual settings to manage or "my VSCode formats differently than yours" conversations.
The linter runs separately from the formatter. You'll see lint errors as red underlines in the editor, same as ESLint. Biome's error messages are better more specific, with suggested fixes that actually make sense rather than a link to a GitHub issue from 2019.
The part most people get wrong
Teams install Biome alongside ESLint and Prettier, then wonder why they're getting conflicting suggestions.
Biome and ESLint will disagree. Biome and Prettier will fight over quote style, trailing commas, bracket spacing. Your editor shows contradictory fixes. CI passes locally and fails remotely depending on which tool ran last.
Pick one. Biome covers what ESLint and Prettier do, at roughly 25x the speed on comparable codebases. If you're starting a new project, there's no reason to bring ESLint or Prettier along. If you're migrating, disable Prettier first, then remove ESLint plugin by plugin as you validate Biome catches the same rules.
Biome has an ESLint rules compatibility page you can map your existing rules to Biome equivalents and find the gaps before you commit to removing ESLint. One genuine gap worth checking: Biome doesn't support every ESLint plugin. If you rely on eslint-plugin-import for module resolution checks, or a framework-specific plugin, verify compatibility first. For most TypeScript projects without unusual plugin requirements, Biome handles it.
Real-world example: a team of four
We set this up for a TypeScript API project at a Series A startup in Jakarta. Four developers, previously using ESLint + Prettier with two separate config files, one .eslintignore, and a prettierrc.json that hadn't been touched in eight months.
Migration took one hour. We ran biome migrate eslint (which reads your existing ESLint config and converts what it can), removed Prettier, updated the pre-commit hook.
PR review comments about formatting dropped to zero in the first week. The lint + format step in CI went from 14 seconds to under 2. Not enormous in isolation but multiply it by 40 pushes a day across four developers.
The non-measurable part: nobody argues about tabs vs spaces anymore. Biome decided. Everyone moved on.
FAQ
Q: Does Biome replace ESLint completely? A: For most TypeScript projects, yes. Biome includes over 200 lint rules covering what ESLint + TypeScript ESLint handle. The gap is framework-specific plugins check Biome's compatibility list if you rely on anything beyond the standard TypeScript ruleset. Support is expanding with each release.
Q: Does the VSCode extension work without biome.json in the project?
A: It falls back to Biome's defaults, but you want the config file committed. That's how you ensure the extension and CI use identical rules. Run npx biome init to generate it and check it in.
Q: What if some team members use a different editor?
A: Biome has plugins for IntelliJ and Zed. For editors without a plugin, a pre-commit hook running biome check --apply covers formatting before code hits the repo. The VSCode extension is a productivity layer, not the enforcement mechanism CI is.
Q: Can I run Biome on a large existing TypeScript codebase?
A: Yes. Run biome check --apply-unsafe on a branch to see what changes. You'll get a full diff of every formatting change at once. Review it, merge it as a single commit, and from that point the codebase is clean. It's less painful than incremental Prettier adoption.
Q: Is Biome stable enough for production use? A: Since version 1.0 (released 2023), yes. The API is stable within major versions. It's used in production at Netlify and several other teams at scale. The 1.x series is the right version to adopt now.
The single biggest mistake teams make with TypeScript tooling is accumulating tools instead of replacing them. Biome isn't another layer to add it's a replacement for two. Install the extension, commit the config, remove Prettier and ESLint, and stop thinking about formatting.
For the complete setup runtime choice, project layout, tsconfig start at .
Internal Reference Logs: