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.
Leia tambem
Fonte
- Biome Docs: https://biomejs.dev/guides/getting-started/