Biome: O assassino do ESLint e Prettier? Guia completo de migração para 2026

O cenário de ferramentas JavaScript acabou de ser abalado. De novo.

Por anos, a combinação ESLint + Prettier foi o padrão indiscutível. Todo projeto, todo tutorial, todo boilerplate—você ia encontrar o mesmo setup. Mas essa dominância tá sendo desafiada por algo mais rápido, mais simples e escrito em Rust: Biome.

Nascido das cinzas do Rome Tools (que captou $4.5M antes de pivotar), o Biome silenciosamente se tornou uma das ferramentas mais empolgantes do ecossistema JavaScript. Não é só mais um linter—é uma toolchain completa que cuida de linting, formatação e mais, tudo num único binário que roda 10-100x mais rápido que as alternativas Node.js.

Mas será que realmente pode substituir ESLint e Prettier em produção? É isso que vamos descobrir.

O que é Biome e por que você deveria ligar?

Biome é uma toolchain unificada pra projetos web. Pensa nele como ESLint + Prettier + (eventualmente) um bundler, tudo empacotado num único binário movido a Rust. Chega de fazer malabarismo com configurações entre múltiplas ferramentas. Chega de se perguntar por que Prettier e ESLint tão brigando por causa de ponto e vírgula.

A história de origem

A jornada do Biome é fascinante. Começou como Rome, um projeto ambicioso do Sebastian McKenzie (criador do Babel e Yarn). O Rome pretendia substituir toda a toolchain JavaScript—linting, formatação, bundling, testes—com uma única ferramenta integrada.

Depois que a Rome Tools (a empresa) fechou em 2023, a comunidade open-source fez um fork do projeto e renomeou pra Biome. Desde então, tá em desenvolvimento ativo, atingiu v1.0 em agosto de 2023 e Biome 2.0 em março de 2025. A versão atual em janeiro de 2026 é v2.3, com mais de 423 regras de lint e funcionalidades inovadoras como type-aware linting.

Características principais que fazem o Biome diferente

1. Performance absurdamente rápida
Não estamos falando de 2x mais rápido. Estamos falando de 10-100x mais rápido:

# Linting de 10.000 arquivos
ESLint: 45.2 segundos
Biome: 0.8 segundos

# Formatação de 10.000 arquivos
Prettier: 12.1 segundos
Biome: 0.3 segundos

Isso não é um benchmark sintético—é performance real em codebases de produção. A diferença de velocidade é tão dramática que muda como você trabalha. O format-on-save realmente parece instantâneo. Pipelines de CI que demoravam minutos no linting agora terminam em segundos.

2. Zero configuração pra começar
Enquanto ESLint exige que você configure regras, Biome vem com defaults sensatos prontos pra usar:

# É isso aí. Você tá lintando e formatando.
npx @biomejs/biome check .

3. Uma ferramenta, uma config
Chega de .eslintrc.js, .prettierrc, .eslintignore, .prettierignore. Só um biome.json:

{
  "$schema": "https://biomejs.dev/schemas/2.3.0/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2
  }
}

4. Mensagens de erro melhores
As mensagens de erro do Biome são feitas pra humanos, não pra máquinas:

file.ts:12:5 lint/correctness/noUnusedVariables ━━━━━━━━━━━━━━━━

  ✖ Essa variável foi declarada mas nunca usada.
  
    10 │ function calculateTotal(items) {
    11 │   const TAX_RATE = 0.08;
  > 12 │   const unusedVar = "hello";
       │         ^^^^^^^^^
    13 │   return items.reduce((sum, item) => sum + item.price, 0);
    14 │ }
  
  ℹ Variáveis não usadas geralmente são sinal de refatoração incompleta.
  ℹ Considere remover essa declaração ou usar no seu código.

Análise profunda de performance

Vamos entrar nos números porque eles são genuinamente impressionantes.

Metodologia do benchmark

Testei em três codebases reais:

• Pequena: 500 arquivos, projeto hobby
• Média: 5.000 arquivos, codebase típica de startup
• Grande: 25.000 arquivos, monorepo enterprise

Hardware: M3 MacBook Pro, 36GB RAM.

Resultados

O speedup fica mais dramático com codebases maiores. O Biome é rápido porque:

1. Paraleliza em todos os cores da CPU por padrão
2. Parseia arquivos uma única vez pra linting e formatação
3. Usa uma representação AST compartilhada na memória

Por que é tão rápido?

Três razões principais:

1. Rust ao invés de Node.js
Biome é escrito em Rust, não JavaScript:

• Sem overhead de startup do V8
• Sem pausas de garbage collection
• Multi-threading nativo sem overhead de worker threads
• I/O de arquivos com memory-mapping

2. Arquitetura unificada
ESLint e Prettier são ferramentas separadas. Quando você roda as duas:

1. ESLint parseia seu arquivo num AST
2. ESLint roda regras, reporta erros
3. Prettier parseia seu arquivo num AST diferente
4. Prettier transforma e gera output

Com Biome:

1. Biome parseia seu arquivo uma vez
2. Biome roda regras de lint e formatação no mesmo passo
3. Pronto

3. Processamento incremental
Biome rastreia mudanças de arquivos e mantém um cache. Arquivos sem alteração são pulados completamente:

# Primeira execução: 2.1s (25.000 arquivos)
# Segunda execução (1 arquivo alterado): 0.05s

Guia de migração: ESLint + Prettier → Biome

Pronto pra fazer a troca? Aqui tá como fazer direito.

Passo 1: Avalie seu setup atual

Primeiro, entenda o que você tá migrando:

# Confere seus plugins do ESLint
cat .eslintrc.* | grep -E "plugin:|extends:"

# Confere regras customizadas
cat .eslintrc.* | grep -E "rules:" -A 100

Faça uma lista de:

• Plugins do ESLint que você usa (eslint-plugin-react, import, etc.)
• Configurações de regras customizadas
• Overrides do Prettier

Passo 2: Instale o Biome

# npm
npm install --save-dev --save-exact @biomejs/biome

# pnpm
pnpm add -D -E @biomejs/biome

# bun
bun add -D -E @biomejs/biome

A flag --save-exact é importante. Biome segue semver estritamente e você vai querer comportamento previsível no time todo.

Passo 3: Inicialize a configuração

npx @biomejs/biome init

Isso cria um biome.json básico:

{
  "$schema": "https://biomejs.dev/schemas/2.3.0/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  }
}

Passo 4: Migre suas regras do ESLint

Biome fornece uma ferramenta de migração:

npx @biomejs/biome migrate eslint --write

Lê seu .eslintrc e adiciona regras equivalentes do Biome ao biome.json.

Pra migração manual, aqui tá o mapeamento de regras comuns:

Passo 5: Migre a configuração do Prettier

Mapeie sua config do Prettier pro formatador do Biome:

// .prettierrc
{
  "printWidth": 100,
  "tabWidth": 2,
  "semi": true,
  "singleQuote": true,
  "trailingComma": "es5"
}

// biome.json equivalente
{
  "formatter": {
    "enabled": true,
    "lineWidth": 100,
    "indentWidth": 2,
    "indentStyle": "space"
  },
  "javascript": {
    "formatter": {
      "semicolons": "always",
      "quoteStyle": "single",
      "trailingCommas": "es5"
    }
  }
}

Passo 6: Atualize seus scripts

// package.json - Antes
{
  "scripts": {
    "lint": "eslint . --ext .js,.ts,.tsx",
    "format": "prettier --write ."
  }
}

// package.json - Depois
{
  "scripts": {
    "lint": "biome lint .",
    "format": "biome format --write .",
    "check": "biome check .",
    "check:fix": "biome check --write ."
  }
}

O comando biome check roda linting e formatação num único passo.

Passo 7: Configure seu editor

VS Code
Instale a extensão Biome VS Code e atualize as settings:

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

Passo 8: Atualize CI/CD

# GitHub Actions
- name: Verificar qualidade do código
  run: npx @biomejs/biome ci .

O comando ci é feito pra ambientes CI—é não-interativo e falha em qualquer erro.

Passo 9: Remova as ferramentas antigas

Quando você tiver certeza de que o Biome tá funcionando:

# Remove ESLint
npm uninstall eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin \
  eslint-plugin-react eslint-plugin-react-hooks

# Remove Prettier
npm uninstall prettier eslint-config-prettier

# Deleta configs antigas
rm .eslintrc* .prettierrc* .eslintignore .prettierignore

O que o Biome não pode fazer (ainda)

Antes de se comprometer totalmente, entenda as limitações atuais.

Plugins do ESLint faltando

Plugins populares sem equivalentes completos no Biome:

Sem Regras Customizadas — RESOLVIDO no 2.0!

Atualização: Biome 2.0 introduziu um sistema de plugins usando GritQL. Agora dá pra escrever regras de lint customizadas:

// biome.grit - Exemplo de regra customizada
language js

`console.log($msg)` => `logger.debug($msg)`

Isso é um marco importante que remove uma das maiores barreiras pra adoção.

Suporte limitado de linguagens

Biome atualmente suporta:

• JavaScript / TypeScript ✅
• JSX / TSX ✅
• JSON ✅
• CSS ✅ (pronto pra produção no 2.0)
• GraphQL ✅
• HTML 🔶 (experimental)
• Astro / Svelte / Vue 🔶 (suporte parcial)

Suporte completo pra Vue SFC e Svelte tá em desenvolvimento ativo.

Abordagem híbrida: Biome + ESLint

Pra muitos times, uma abordagem híbrida faz sentido durante a migração:

// biome.json - Ignora arquivos tratados pelo ESLint
{
  "files": {
    "ignore": ["**/*.vue", "**/*.svelte"]
  }
}

// package.json
{
  "scripts": {
    "lint": "biome check . && eslint --ext .vue .",
    "lint:fix": "biome check --write . && eslint --ext .vue . --fix"
  }
}

Você deveria migrar?

Aqui tá minha avaliação honesta:

Migra agora se:

• Performance é um problema (CI lento, format-on-save lento)
• Você tá começando um projeto novo
• Usa principalmente JS/TS/React sem Vue/Svelte
• Quer configuração de ferramentas mais simples
• Seu time não depende de plugins ESLint de nicho

Espera se:

• Depende muito de regras ESLint customizadas
• Precisa de suporte pra Vue ou Svelte
• Usa eslint-plugin-jsx-a11y pra acessibilidade
• Seu setup de ESLint "simplesmente funciona" e não é lento

O veredito

Biome tá pronto pra produção pra maioria dos projetos JavaScript/TypeScript/React. A melhoria de velocidade é real e significativa. A complexidade de configuração reduzida é uma melhoria genuína de qualidade de vida.

Porém, não é um drop-in replacement pra todo setup de ESLint. Se você depende de plugins que o Biome não suporta, vai precisar:

1. Aceitar a lacuna e adicionar práticas de code review manual
2. Rodar tanto Biome quanto ESLint (abordagem híbrida)
3. Esperar o sistema de plugins do Biome (tá no roadmap)

Novidades no Biome 2.0+

Biome 2.0 (lançado em março 2025) trouxe melhorias importantes:

• Sistema de Plugins: Escreva regras de lint customizadas com GritQL
• Linting Type-Aware: Regras que entendem tipos TypeScript sem o compilador TS
• Suporte CSS: Formatação e linting prontos pra produção
• Formatação HTML: Suporte experimental
• Análise Multi-arquivo: Regras podem coletar info de outros arquivos
• Melhores Supressões: // biome-ignore-all e // biome-ignore-start/end
• Melhor Ordenação de Imports: Mais controle e defaults melhores
• Astro/Svelte/Vue: Suporte parcial pra arquivos de frameworks

A versão atual (v2.3) tem 423+ regras de lint do ESLint, typescript-eslint e mais.

Olhando pro futuro

O time do Biome continua empurrando limites:

• Suporte completo Vue/Svelte SFC: Prioridade máxima
• Ecossistema de plugins expandido: Mais padrões GritQL e plugins da comunidade
• Biome Language Server 2.0: Integração IDE ainda mais rápida
• Suporte Enterprise: Disponível desde janeiro 2025

O momentum é real. Biome foi de 5.000 pra 100.000+ estrelas no GitHub desde o lançamento. Grandes empresas tão adotando. Com o sistema de plugins do Biome 2.0 resolvendo o problema de regras customizadas, a questão não é se o Biome vai ter sucesso—é quão rápido o ecossistema vai mudar.

Pra projetos novos, Biome agora é a escolha padrão. Pra projetos existentes, comece com abordagem híbrida e migre incrementalmente.

Uma coisa é clara: a era ESLint + Prettier não acabou, mas ganhou competição séria. E essa competição foi escrita em Rust. 🦀