O toolchain JavaScript tem um problema de complexidade que nunca foi resolvido de forma satisfatória. Para configurar linting e formatação num projeto TypeScript moderno, você precisa do ESLint, do Prettier, do @typescript-eslint/parser, do @typescript-eslint/eslint-plugin, do eslint-config-prettier para desativar regras conflitantes entre os dois — e ainda assim, ao final, vai ter que resolver manualmente quando os dois discordam sobre formatação de vírgulas. No mínimo quatro arquivos de configuração diferentes. Centenas de dependências transitivas. Um npm install que às vezes demora mais que o build inteiro em projetos menores.

O Biome é a proposta de resolver esse problema com uma única ferramenta. Linter, formatter, organizador de imports — tudo num único binário escrito em Rust, sem precisar do Node.js para executar.

Isso era atraente no papel há dois anos. O que mudou em 2026 é que deixou de ser atraente para se tornar uma escolha viável em produção.

O que é o Biome e de onde veio

O Biome surgiu em setembro de 2023 como um fork comunitário do Rome — projeto iniciado por Sebastian McKenzie, o criador do Babel e do Yarn — depois que o desenvolvimento do Rome estagnou e o repositório ficou praticamente sem atividade. A mudança de nome foi estratégica: romper com a reputação de projeto abandonado e recomeçar com foco em entregas concretas.

O crescimento foi expressivo. Em 2025, o pacote npm ultrapassou a marca de 1 milhão de downloads mensais. O projeto ganhou contribuidores ativos, passou por releases consistentes e hoje está na série 2.x com mais de 420 regras de lint cobrindo ESLint core, TypeScript ESLint, React, Unicorn e outras fontes populares.

O Biome 2.0 trouxe duas adições relevantes: um sistema de plugins via GritQL que permite escrever regras customizadas, e o início do suporte experimental a Vue, Svelte e Astro. A versão foi um sinal de que o projeto saiu da fase "promissor" para a fase "maduro".

A promessa central permanece a mesma: um único binário que substitui o conjunto ESLint + Prettier + import sorter. Sem dependências adicionais de runtime, sem arquivos de configuração espalhados em .eslintrc.js, .prettierrc, .eslintignore e .prettierignore.

Performance: o que o Rust muda na prática

Os benchmarks do Biome são diretos. Em testes com 10.000 arquivos JavaScript e TypeScript, os números publicados pela equipe são os seguintes:

  • Linting: 0,8 segundos com Biome contra 45,2 segundos com ESLint (56x mais rápido)
  • Formatação: 0,3 segundos com Biome contra 12,1 segundos com Prettier (40x mais rápido)

A documentação oficial sintetiza em "até 97% mais rápido que o Prettier". Em projetos de médio porte, o check completo se torna imperceptível.

O motivo técnico tem duas camadas. A primeira é óbvia: Rust compila para binário nativo, sem overhead de VM, sem pausas de garbage collector, sem warmup de JIT. A segunda é mais sutil: o Biome foi desenhado para compartilhar a mesma árvore de sintaxe concreta (CST) entre o formatter e o linter. O ESLint e o Prettier parseiam o mesmo código-fonte de forma independente, cada um construindo sua própria representação interna. O Biome parseia uma vez e usa o resultado para ambas as análises.

Na prática, isso muda o ciclo de desenvolvimento. O check na hora de salvar o arquivo no editor é instantâneo. Em pipelines de CI em monorepos, a etapa de lint deixa de ser um gargalo perceptível.

Biome na prática: configuração e primeiros passos

A instalação é direta:

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

O comando init cria um biome.json na raiz do projeto. Uma configuração funcional para TypeScript com as opções mais comuns fica assim:

{
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "double",
      "trailingCommas": "es5",
      "semicolons": "always"
    }
  }
}

No Biome 2.x, a organização de imports é configurada via assist.actions.source.organizeImports. A chave top-level organizeImports do Biome 1.x foi removida. O biome check --write organiza imports por padrão na maioria das configurações sem precisar declarar explicitamente.

Os comandos do dia a dia:

# Verifica linting, formatação e organização de imports
npx biome check .

# Aplica todas as correções automáticas
npx biome check --write .

# Só linting, sem formatação
npx biome lint .

# Só formatação
npx biome format --write .

A integração com VS Code funciona via extensão oficial (biome.biome), que adiciona highlight de erros em tempo real e format-on-save lendo o biome.json do projeto diretamente.

No package.json, a migração dos scripts fica assim:

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

Um detalhe prático: o Biome aceita biome.json e biome.jsonc (com comentários), o que facilita documentar decisões de configuração diretamente no arquivo.

Migrando do ESLint e Prettier

Para projetos existentes, o Biome oferece comandos de migração automática que cobrem boa parte do trabalho pesado:

# Lê .eslintrc e converte as regras para biome.json
npx @biomejs/biome migrate eslint --write

# Lê .prettierrc e converte as opções para biome.json
npx @biomejs/biome migrate prettier --write

O migrate eslint converte automaticamente em torno de 70 a 80% das regras para projetos que usam ESLint core e TypeScript ESLint sem plugins muito customizados. As regras sem equivalente direto são adicionadas ao biome.json com comentários explicativos, deixando claro o que precisa de atenção manual.

As opções do Prettier têm correspondência direta no Biome:

  • printWidth corresponde a formatter.lineWidth
  • tabWidth corresponde a formatter.indentWidth
  • useTabs corresponde a formatter.indentStyle (valor: "tab" ou "space")
  • singleQuote corresponde a javascript.formatter.quoteStyle
  • trailingComma corresponde a javascript.formatter.trailingCommas
  • semi corresponde a javascript.formatter.semicolons

Após a migração, o passo mais importante é rodar biome check em toda a base de código e revisar o diff gerado. Discrepâncias de formatação entre Biome e Prettier são esperadas: as duas ferramentas têm opiniões próprias sobre alguns casos de borda, como espaçamento dentro de objetos, quebras de linha em expressões longas e alguns casos de JSX. O diff vai mostrar exatamente o que mudou.

Quando o Biome ainda não é suficiente

Ser direto aqui: o Biome não substitui o ESLint em todos os cenários.

O Biome tem a regra useExhaustiveDependencies que verifica os arrays de dependência do useEffect e useCallback — mas com comportamento diferente do react-hooks/exhaustive-deps. A implementação do Biome pode sinalizar dependências declaradas como desnecessárias que o ESLint ignoraria, e a cobertura de custom hooks requer configuração explícita no biome.json. Times com ajustes finos nesse plugin devem comparar o comportamento antes de migrar completamente.

Acessibilidade também tem cobertura parcial. O eslint-plugin-jsx-a11y cobre dezenas de regras específicas para ARIA e semântica HTML que o Biome só cobre parcialmente. Projetos com requisitos sérios de acessibilidade precisam verificar a lista de regras faltantes antes de remover o ESLint completamente.

Para Vue e Svelte, o suporte experimental de 2026 é um progresso, mas a paridade com os plugins maduros do ESLint para esses frameworks ainda está distante. Projetos nesses ecossistemas vão conviver com as duas ferramentas por algum tempo.

O sistema de plugins via GritQL, lançado no Biome 2.0, endereça parte desse problema no longo prazo. Escrever regras em GritQL tem uma curva de aprendizado própria, e o ecossistema de plugins comunitários ainda é pequeno comparado ao do ESLint.

Para quem quer usar o Biome sem abrir mão do ESLint completamente, o pacote eslint-config-biome desativa as regras do ESLint que já têm equivalente no Biome, evitando conflitos e duplicação.

Conclusão

O Biome chegou num ponto em que a pergunta deixou de ser "vai substituir o ESLint?" e passou a ser "quais são os cenários em que ainda não substitui?". Para projetos TypeScript sem dependência pesada de plugins de acessibilidade ou de regras específicas de hooks, a substituição hoje é direta, sem concessões significativas.

A performance é o argumento mais visível, mas o ganho real está em complexidade operacional. Uma ferramenta no lugar de quatro, um arquivo de configuração, um comando de check. Em times que gastam tempo configurando e mantendo toolchain, isso tem valor direto que vai além dos benchmarks.

A roadmap de 2026 aponta para maturidade crescente em suporte a CSS, HTML e frameworks baseados em componentes. O espaço consolidado pelo ESLint em dez anos está sendo preenchido de forma gradual, mas com uma velocidade que dois anos atrás não parecia possível.

Referências pesquisadas nesta publicação