Biome: quando substituir ESLint e Prettier em projetos TypeScript

Resposta direta: vale considerar Biome quando o seu projeto quer menos configuracao, mais velocidade e uma experiencia unificada para lint e formatacao. Se a sua stack TypeScript depende de um ecossistema enorme de plugins do ESLint ou de regras muito especificas de framework, a troca ainda pede cautela.

O que faz o Biome ganhar espaco

O apelo do Biome e simples: em vez de manter formatter, linter e parte do fluxo de analise espalhados em ferramentas diferentes, ele tenta centralizar o essencial num setup menor. Isso reduz tempo de onboarding, quantidade de arquivos de configuracao e a manutencao de dependencias que raramente agregam valor direto ao produto.

Em times pequenos e medios, isso pesa bastante. Ninguem quer perder uma tarde para acertar conflitos entre parser, plugin, preset e formatador so para conseguir rodar CI com consistencia.

Quando a substituicao faz sentido

Na pratica, Biome tende a encaixar melhor em tres cenarios:

projetos novos em TypeScript que ainda nao carregam heranca de regras antigas;
produtos internos ou SaaS em que padronizacao e velocidade valem mais que hiperpersonalizacao;
repositorios com varias apps e bibliotecas onde reduzir dependencia melhora a manutencao.

Se o seu foco e previsibilidade, a troca pode simplificar bastante a base. Esse ganho aparece com clareza quando combinado com boas praticas de TypeScript moderno e com uma disciplina real de codigo limpo em TypeScript.

Quando ainda nao vale trocar

Nem todo projeto precisa correr para a migracao. Eu seguraria a mudanca quando:

o time depende de plugins ESLint muito especificos;
ha regras customizadas ligadas a arquitetura ou seguranca;
o repositorio mistura stacks antigas que ainda nao foram estabilizadas;
voce nao tem janela para revisar warnings e ajustar convencoes.

O erro aqui e tratar “menos config” como argumento suficiente. Ferramenta boa e a que resolve o problema real do time. Se ESLint e Prettier estao maduros, automatizados e sem atrito, Biome nao precisa entrar so porque virou assunto.

O ganho concreto para times brasileiros

Em consultorias, squads de produto e freelas que tocam mais de um projeto, setup curto vira economia real. Menos tempo mantendo pipeline significa mais tempo revisando arquitetura, tipagem e regra de negocio. Isso importa ainda mais em stacks que ja foram simplificadas por bundlers e frameworks modernos, como comentamos no texto sobre o fim do Create React App e a consolidacao do Vite e de frameworks opinativos.

Tambem ha um ganho de percepcao: ferramenta unica reduz discussao improdutiva sobre estilo e deixa review de PR mais focado no que interessa.

Como decidir sem dogma

Eu faria uma prova pequena:

escolha um pacote ou app isolado;
rode Biome em paralelo por alguns dias;
compare velocidade, ruido de regras e impacto no CI;
veja se alguem sentiu falta de algo realmente importante.

Se a resposta for “nao”, a migracao ganha argumento tecnico de verdade.

Minha leitura

Biome nao e substituto automatico de ESLint e Prettier. Ele e uma aposta forte para times que querem stack mais enxuta e operacao menos cansativa. Em projeto TypeScript novo ou pouco acoplado a plugins, eu testaria sem medo. Em base legacy complexa, migraria por partes.