Decidimos não esperar pelo linter perfeito: migração para o ESLint V9 e adoção híbrida do Biome

Compartilhamos a experiência do chapter de frontend da Lemonbase ao migrar para o ESLint V9 em resposta ao fim do suporte ao ESLint V8 e resolver problemas de desempenho com a adoção híbrida do Biome.

Contexto da adoção

• Em setembro de 2024, foi anunciado o fim do suporte ao ESLint V8, tornando a migração para o V9 indispensável para continuar recebendo patches de segurança e correções de bugs
• A partir do V9, a configuração baseada em .eslintrc.js foi descontinuada, e o Flat Config passou a ser o padrão
• Era necessário verificar cerca de 400 regras, uma estrutura de arquivos de configuração dividida em duas partes e a compatibilidade de vários plugins

Processo de migração

• A ferramenta oficial de migração do ESLint ficou aquém do esperado, pois basicamente apenas envolvia a configuração com @eslint/compat
• Um rascunho foi gerado com ferramentas de IA, mas surgiram várias regras omitidas e problemas de compatibilidade
• No fim, foi feita uma revisão completa comparando as regras do V8 e do V9 uma a uma em uma planilha

Problemas de desempenho após a migração

• Depois da atualização para o V9, em vez de melhorar, o tempo ficou 30 segundos mais lento: de 154 s para 184 s
• A regra import/no-cycle ficou 10 vezes mais lenta em relação ao V8, passando a representar 45,8% do total
• A regra prettier/prettier também chegou a 10,2%, e a sobrecarga de parsing duplo virou um gargalo

Adoção híbrida do Biome

• Em vez de uma substituição completa, a abordagem mudou para “usar juntos e focar no ganho”
• O Prettier foi substituído pelo Biome Formatter, reduzindo o tempo de formatação de 14 s para 2 s
• O ESLint passou a cuidar apenas das regras customizadas do projeto

Resultado final

• ESLint V8: 154 s → ESLint V9: 184 s
• Apenas ESLint → híbrido Biome + ESLint: ~20 s

O que aprenderam

• Ao delegar a migração para uma IA, é preciso primeiro fazê-la montar um plano, depois revisar com atenção e definir critérios de sucesso com clareza, como por exemplo obter o mesmo resultado do V8
• Em vez de esperar pela ferramenta perfeita, às vezes o caminho mais rápido é combinar bem as ferramentas disponíveis agora

Pontos de atenção

• Ao usar as duas ferramentas juntas, é preciso manter tanto o eslint.config.mjs quanto o biome.json, e podem surgir conflitos entre regras
• É necessário definir claramente qual regra ficará sob responsabilidade de cada ferramenta e explicar essa divisão de papéis durante o onboarding de novos membros da equipe

[chamchi]

Em vez de eslint e prettier, vocês não pensam em usar oxlint e oxfmt?
Mantendo um mapeamento de configuração 1 para 1, a velocidade fica no mínimo dezenas de vezes mais rápida

[selene]

Parece um texto que pode trazer bons insights para quem ainda está enfrentando problemas de performance de linting.

Nós também tivemos uma experiência parecida no ano passado: ao melhorar nosso setup para usar oxc (oxlint) e ESLint de forma híbrida, conseguimos reduzir um linting que levava mais de 200 segundos para menos de 15 segundos.

No começo, eu também fiz a migração de forma meio bruta usando IA, mas regras omitidas ou alteradas continuavam aparecendo, então cheguei a pensar em revisar uma por uma.
Em vez disso, usei IA para escrever um script que extrai as regras suportadas pelo oxc, e ajustei o processo para deixar ativadas no ESLint apenas as regras que o oxc não suporta. Assim, ficou muito mais fácil atualizar periodicamente as novas regras que passam a ser suportadas...

No início, esse processo era semiautomatizado, mas agora definimos isso como uma Skill e basta executar com o Claude Code, então a carga também diminuiu bastante, o que foi ótimo.