Rome vs ESLint: o que aconteceu e o que usar no CI
O Rome pretendia substituir o ESLint e o Prettier por um toolchain rápido; hoje seu sucessor mantido é o Biome, então a escolha prática é Biome vs ESLint.
O Rome era um ambicioso toolchain all-in-one de JavaScript (lint, format e mais) posicionado contra o ESLint e o Prettier. O desenvolvimento ativo migrou para seu fork Biome; o Rome em si está efetivamente superado. O ESLint continua o linter padrão, rico em plugins.
| Rome | ESLint | |
|---|---|---|
| Status | Superado pelo Biome | Ativamente mantido |
| Escopo | Lint + format (all-in-one) | Lint (Prettier para format) |
| Velocidade | Rápido (Rust) | Mais lento |
| Ecossistema | Limitado (agora via Biome) | O maior |
| Recomendado hoje | Use o Biome no lugar | Sim, amplamente usado |
No CI
Não adote o Rome para novos pipelines - ele não é mais o projeto ativo; seu sucessor Biome carrega a mesma ideia rápida e all-in-one com manutenção contínua. Então a real decisão de CI é Biome (lint e format rápidos e de baixa config) vs ESLint (o padrão com o maior ecossistema de plugins). Se você encontrou o Rome em uma config antiga, planeje uma migração para o Biome ou o ESLint.
Caminho prático
Para um toolchain all-in-one rápido, avalie o Biome; para cobertura máxima de regras e plugins, o ESLint. O linting roda em managed runners; runners gerenciados mais rápidos encurtam a etapa de lint em bases de código grandes.
O veredito
O Rome está superado - não comece por ele. Para um linter/formatter all-in-one rápido, use o Biome; para o ecossistema mais amplo de regras e plugins, use o ESLint. Migre qualquer config legada de Rome para uma dessas.