What Is Biome? The Fast Linter and Formatter AI Coding Tools Are Switching To

Why AI Coders Need to Know This

If you've been vibe coding for a while, you've probably seen the old setup: your AI creates a project, adds an .eslintrc.json for catching code problems, a .prettierrc for formatting, then installs six or seven npm packages to make them play nice together. Maybe it throws in eslint-config-prettier to stop the two tools from fighting over semicolons.

That setup works. It's been the industry standard for years. But it has real problems that hit vibe coders especially hard:

• Plugin dependency hell: ESLint needs packages like @typescript-eslint/parser, @typescript-eslint/eslint-plugin, eslint-plugin-react, eslint-config-prettier — all at compatible versions. AI tools frequently get version combinations wrong.
• Two configs that fight: ESLint and Prettier disagree on formatting rules. You need eslint-config-prettier to tell ESLint to back off, or they produce conflicting red underlines in VS Code.
• Slow on large projects: ESLint can take 10-30 seconds to lint a medium codebase. In CI pipelines, that adds up fast.
• Config complexity: ESLint 9 introduced a completely new "flat config" format. AI tools sometimes generate the old .eslintrc format for ESLint 9, which breaks immediately.

Biome fixes all of this. One tool. One config file. No plugins to install. And it runs in milliseconds instead of seconds.

This matters for vibe coders because the fewer moving parts between you and working code, the fewer things break. When your AI generates a Biome setup, there are exactly two things to understand: the biome.json config file and the biome command. That's it.

What Biome Actually Does

Biome does two jobs that used to require two separate tools:

1. Formatting (replaces Prettier) — It takes your messy, inconsistently-spaced code and makes it clean and uniform. Tabs vs spaces, semicolons or not, single quotes vs double quotes, line width — all handled automatically. You write code however you want; Biome makes it look professional on save.

2. Linting (replaces ESLint) — It reads your code and flags actual problems: unused variables, unreachable code, missing await on async functions, deprecated patterns, accessibility issues in JSX, and about 270 other rules. These aren't style opinions — they're bug catchers.

It also does a third thing that neither ESLint nor Prettier do: import sorting. Biome automatically organizes your import statements at the top of each file, grouping them logically and alphabetically. This is one of those small things that makes AI-generated code look polished instead of random.

Languages Biome Supports

• JavaScript and JSX
• TypeScript and TSX
• JSON and JSONC (JSON with comments)
• CSS (stable since Biome 1.8)
• GraphQL (in progress)
• HTML (planned)

If your project is JavaScript/TypeScript-based (React, Next.js, Svelte, Node.js, Astro) — Biome covers your main files. For everything else (Markdown, YAML, etc.), you might still want Prettier alongside it, but for your actual code files, Biome is a complete replacement.

Why It's 35x Faster (Without You Doing Anything)

You don't need to understand the engineering to benefit from this, but the short version is worth knowing:

ESLint and Prettier are written in JavaScript. They run on Node.js, which interprets code at runtime. That's fine for small projects, but JavaScript is fundamentally slower at the kind of heavy text parsing that linters and formatters do.

Biome is written in Rust. Rust compiles to native machine code — the same kind of code your operating system runs. It also handles memory without a garbage collector, so there are no pauses. And Biome processes multiple files in parallel by default.

The result: formatting 2,104 files that takes Prettier about 7 seconds takes Biome about 0.2 seconds. Linting the same project with ESLint takes around 12 seconds; Biome does it in about 0.3 seconds. These aren't theoretical benchmarks — they're from the Biome team's published performance tests on real-world codebases.

Real Scenario

You're starting a new Next.js project with Claude Code (or Cursor, or Copilot). You ask it to set up the project with linting and formatting. Instead of the familiar .eslintrc.json + .prettierrc combo, it generates a single biome.json file.

Set up a new Next.js 15 project with TypeScript.
Add linting and formatting — I want it fast and simple.
Use Biome instead of ESLint + Prettier.
Configure it for React with strict rules enabled.

What Your AI Generated

Here's the biome.json your AI probably created at the project root:

{
  "$schema": "https://biomejs.dev/schemas/1.9.4/schema.json",
  "vcs": {
    "enabled": true,
    "clientKind": "git",
    "useIgnoreFile": true
  },
  "organizeImports": {
    "enabled": true
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 80
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "correctness": {
        "noUnusedVariables": "error",
        "noUnusedImports": "error",
        "useExhaustiveDependencies": "warn"
      },
      "suspicious": {
        "noExplicitAny": "warn",
        "noConsoleLog": "warn"
      },
      "style": {
        "noNonNullAssertion": "warn",
        "useConst": "error"
      },
      "a11y": {
        "recommended": true
      }
    }
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "double",
      "semicolons": "always",
      "trailingCommas": "all"
    }
  },
  "files": {
    "ignore": [
      "node_modules",
      ".next",
      "dist",
      "build",
      "coverage"
    ]
  }
}

And in package.json, it added:

{
  "devDependencies": {
    "@biomejs/biome": "^1.9.4"
  },
  "scripts": {
    "lint": "biome check .",
    "lint:fix": "biome check --write .",
    "format": "biome format --write ."
  }
}

That's it. One dev dependency. No plugins. No config packages. No compatibility matrices.

Understanding Each Part of biome.json

Let's break down what each section does in plain English. You don't need to memorize this — just know where to look when something needs changing.

The $schema Line

"$schema": "https://biomejs.dev/schemas/1.9.4/schema.json"

This gives VS Code autocomplete and validation inside biome.json. When you start typing a property name, your editor will suggest valid options. If you type something wrong, it'll underline it. Think of it as built-in documentation.

The vcs Section

"vcs": {
  "enabled": true,
  "clientKind": "git",
  "useIgnoreFile": true
}

This tells Biome to respect your .gitignore file. If a file is git-ignored (like node_modules or build output), Biome won't waste time linting or formatting it. Simple and smart.

The organizeImports Section

"organizeImports": {
  "enabled": true
}

Automatically sorts and groups your import statements. Before Biome, you needed a separate ESLint plugin (eslint-plugin-import) or Prettier plugin for this. Biome does it natively.

The formatter Section

"formatter": {
  "enabled": true,
  "indentStyle": "space",
  "indentWidth": 2,
  "lineWidth": 80
}

This controls how your code looks. Spaces or tabs, how wide the indentation is, and how long a line can get before Biome wraps it. These are the Prettier-equivalent settings. The defaults match what most JavaScript projects use.

The linter Section

This is the big one — it controls what Biome flags as problems:

• "recommended": true — Turns on Biome's curated set of ~170 rules that catch real bugs without being noisy. This is the equivalent of eslint:recommended plus @typescript-eslint/recommended.
• correctness — Rules that catch actual bugs. noUnusedVariables and noUnusedImports flag dead code. useExhaustiveDependencies is the React hooks dependency rule (equivalent to react-hooks/exhaustive-deps).
• suspicious — Code that's probably wrong. noExplicitAny warns when TypeScript types are being bypassed. noConsoleLog catches debug logging you forgot to remove.
• style — Code quality preferences. useConst enforces const over let when a variable is never reassigned.
• a11y — Accessibility rules for JSX. Missing alt text on images, invalid ARIA attributes, clickable divs without keyboard support — the kind of stuff that makes websites unusable for people with disabilities.

The javascript.formatter Section

"javascript": {
  "formatter": {
    "quoteStyle": "double",
    "semicolons": "always",
    "trailingCommas": "all"
  }
}

JavaScript-specific formatting. Double quotes or single quotes. Semicolons or not. Trailing commas (that comma after the last item in a list — it actually prevents git diff noise). These override the general formatter for JS/TS files specifically.

The files.ignore Section

"files": {
  "ignore": [
    "node_modules",
    ".next",
    "dist",
    "build",
    "coverage"
  ]
}

Folders to skip entirely. If you enabled the VCS integration above, Biome already skips git-ignored paths — but being explicit here is a safety net. Your AI will usually include common output directories.

How to Set Up Biome (From Zero)

If your AI didn't set it up for you, or you want to add Biome to an existing project, here's the full process:

Step 1: Install Biome

npm install --save-dev @biomejs/biome

That's one package. Compare this to a typical ESLint + Prettier setup that needs 5-8 packages.

Step 2: Create the Config

npx @biomejs/biome init

This generates a starter biome.json with sensible defaults. You can customize it later — or ask your AI to customize it for your stack.

Step 3: Add Scripts to package.json

{
  "scripts": {
    "lint": "biome check .",
    "lint:fix": "biome check --write .",
    "format": "biome format --write ."
  }
}

• biome check . — Runs both the linter and formatter checks on everything. Reports problems without changing files.
• biome check --write . — Same thing, but automatically fixes everything it can.
• biome format --write . — Only formatting, no lint rules. Useful when you just want clean code fast.

Step 4: Install the VS Code Extension

Search for "Biome" in the VS Code extensions panel and install it. Then add this to your project's .vscode/settings.json:

{
  "editor.defaultFormatter": "biomejs.biome",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "quickfix.biome": "explicit",
    "source.organizeImports.biome": "explicit"
  }
}

Now every time you save a file, Biome formats it, sorts imports, and applies safe lint fixes — all instantly.

Migrating from ESLint + Prettier

Already have an existing project with ESLint and Prettier? Biome has built-in migration commands that read your existing configs and translate them:

# Install Biome first
npm install --save-dev @biomejs/biome

# Migrate your ESLint config to biome.json rules
npx @biomejs/biome migrate eslint

# Migrate your Prettier config to biome.json formatting
npx @biomejs/biome migrate prettier

These commands read your .eslintrc (or eslint.config.js) and .prettierrc, map the rules to Biome equivalents, and write them into biome.json. Not every ESLint rule has a Biome equivalent — the migration will tell you which rules couldn't be mapped.

After migrating:

1. Run npx @biomejs/biome check --write . to format and lint everything with Biome
2. Review the output — make sure nothing looks wrong
3. Remove old config files: .eslintrc*, .prettierrc*, .eslintignore, .prettierignore
4. Uninstall old packages: npm uninstall eslint prettier @typescript-eslint/parser @typescript-eslint/eslint-plugin eslint-config-prettier eslint-plugin-react (and any others)
5. Update your CI scripts to use biome check instead of eslint and prettier --check

What AI Gets Wrong About Biome

AI coding tools are good at generating Biome configs, but they make specific mistakes you should watch for:

1. Generating Both ESLint AND Biome Configs

This is the most common issue. Your AI scaffolds a project and creates both a .eslintrc.json and a biome.json. Now you have two linters fighting over the same files — duplicate warnings, conflicting formatting rules, and developer confusion.

The fix: Pick one. If you see both files, ask your AI: "I have both ESLint and Biome configured. Remove the ESLint setup and consolidate everything into biome.json."

2. Using Outdated biome.json Schema Versions

AI models are trained on data with a cutoff date. They might generate a $schema URL pointing to Biome 1.5 when you've installed 1.9. This won't break anything, but you'll miss newer rules and config options.

The fix: After your AI generates the config, update the schema URL to match your installed version. Check with npx @biomejs/biome --version.

3. Over-Configuring Rules That Are Already in "recommended"

AI tends to be verbose. It'll set "recommended": true and then explicitly re-declare twenty rules that are already part of the recommended set. This isn't harmful — it's just noise that makes the config harder to read.

The fix: Only explicitly declare rules when you want to change them from the recommended default (like changing a "warn" to an "error" or turning something off).

4. Missing the Next.js Ignore Patterns

If you're using Next.js, Biome will try to lint the .next build directory — thousands of generated files. Your AI might forget to add it to the ignore list.

The fix: Always check that .next, node_modules, and any build output directories are in files.ignore.

5. Not Setting Up the VS Code Extension

The AI will generate the config but forget to create the .vscode/settings.json that makes format-on-save work. Without this, you have Biome installed but not integrated into your workflow.

The fix: Always ask: "Also set up the VS Code settings for Biome with format-on-save and organize imports on save."

How to Debug Biome Issues

When something isn't working right, here are the commands and strategies that solve 90% of Biome problems:

"Biome isn't catching errors" or "No underlines in VS Code"

1. Check the Biome VS Code extension is installed and enabled
2. Make sure biome.json exists in your project root
3. Run npx @biomejs/biome check . in the terminal — if it works there but not in VS Code, restart VS Code
4. Check VS Code Output panel → select "Biome" from the dropdown for error messages

"Biome is formatting differently than I expected"

# See what Biome would change without changing it
npx @biomejs/biome format --write=false .

# Check a specific file
npx @biomejs/biome format --write=false src/app/page.tsx

"I'm getting a rule I don't understand"

Every Biome lint message includes the rule name, like lint/correctness/noUnusedVariables. Search that exact string on biomejs.dev/linter/rules/ for the full explanation, examples, and how to disable it.

To disable a specific rule:

{
  "linter": {
    "rules": {
      "correctness": {
        "noUnusedVariables": "off"
      }
    }
  }
}

To ignore a rule on one line, add a comment above it:

// biome-ignore lint/correctness/noUnusedVariables: keeping for future use
const tempVar = "something";

"CI is failing on Biome checks"

Run locally first:

npx @biomejs/biome check .

If there are fixable issues:

npx @biomejs/biome check --write .

Commit the fixes and push again. Most Biome CI failures are formatting issues that --write fixes instantly.

Biome vs ESLint + Prettier: When to Use Which

Biome isn't better in every situation. Here's the honest breakdown:

Use Biome when: Starting a new project, your stack is JS/TS-based, you want simplicity, or you're tired of dependency conflicts.

Stick with ESLint when: You need framework-specific plugins Biome doesn't cover yet (like eslint-plugin-tailwindcss for class ordering), you're on a large team with deeply customized ESLint rules, or your existing config is working perfectly and migration isn't worth the effort.

For most vibe coders starting new projects: Biome is the better choice. Less config, fewer things to break, faster feedback. You can always add ESLint later for specific plugins if you need them.

The Rome → Biome Backstory (30 Seconds)

You might see references to "Rome" or "Rome Tools" in older articles and AI responses. Here's what happened: Rome was a company that tried to build this exact tool — one linter-formatter to rule them all. The company ran out of funding in 2023 and shut down. The open-source community forked the code and renamed it Biome. Same codebase, same goals, active and well-funded community.

If your AI ever generates a rome.json config, it's hallucinating — Rome doesn't exist anymore. Tell it: "Rome was renamed to Biome. Use biome.json instead."

What's Next

Now that you understand what Biome does and how it works:

• Already using ESLint? Read our guide on What Is ESLint? to understand what you'd be migrating from — and decide if migration is worth it for your project.
• Confused about formatting? Our What Is Prettier? guide explains the formatting half of what Biome replaces.
• New to TypeScript? Biome has first-class TypeScript support. Learn What TypeScript Is and why your AI keeps generating .ts files.
• Want to try it right now? Ask your AI: "Add Biome to this project. Remove any existing ESLint or Prettier configs. Set up VS Code format-on-save." Then run npm run lint to see it in action.

Biome is part of a larger trend in the JavaScript ecosystem: tools written in Rust replacing older JavaScript-based tools. Vite replaced Webpack. Turbopack is replacing Webpack in Next.js. And Biome is replacing ESLint + Prettier. As a vibe coder, you don't need to learn Rust — you just need to know that when your AI picks the Rust-based option, it's usually picking the faster, simpler one.

Frequently Asked Questions

What is Biome?

Biome is a fast, all-in-one linter and code formatter for JavaScript, TypeScript, JSX, TSX, JSON, and CSS. It's written in Rust (which is why it's so fast) and replaces both ESLint and Prettier with a single tool and a single config file called biome.json.

Is Biome better than ESLint and Prettier?

For most new projects, yes. Biome is roughly 35x faster than ESLint + Prettier combined, has zero configuration dependencies (no plugin packages to install), produces consistent formatting with no config fights, and catches 270+ lint rules out of the box. The main trade-off is that ESLint has a larger plugin ecosystem for niche frameworks.

Why did my AI generate a biome.json instead of .eslintrc?

AI coding tools like Claude, Cursor, and Copilot are trained on recent codebases where Biome adoption is growing fast. They recognize that Biome is simpler to configure (one file, no plugin dependencies) and faster to run. If you didn't specify ESLint, your AI likely chose Biome as the modern default.

Can I use Biome and ESLint together?

You can, but you probably shouldn't. Running both creates rule conflicts, duplicate warnings, and slower CI. The recommended approach is to pick one. If you're starting fresh, use Biome. If you have an existing ESLint setup that works, keep it until you're ready to migrate fully.

How do I migrate from ESLint and Prettier to Biome?

Run npx @biomejs/biome migrate eslint and npx @biomejs/biome migrate prettier to auto-generate a biome.json from your existing configs. Then run npx @biomejs/biome check --write . to format and lint everything. Remove your old .eslintrc, .prettierrc, and their dependencies from package.json.