Oxlint – Linter de JavaScript escrito em Rust
Um novo linter de JavaScript escrito em Rust, o Oxlint, está chamando atenção por ser dezenas a milhares de vezes mais rápido que o ESLint em bases de código grandes, especialmente em pipelines de CI. Os comentários acolhem o desempenho e a história de dependências mais simples, mas destacam grandes trade-offs: cobertura limitada de regras, falta de um ecossistema maduro de plugins e regras personalizadas, e o risco de fragmentar as ferramentas entre múltiplas substituições baseadas em Rust, como Biome e Bun. O debate reflete uma tendência mais ampla de reescrever ferramentas de JS em linguagens compiladas, equilibrando velocidade bruta e simplicidade contra configurabilidade, extensibilidade e sustentabilidade no longo prazo.
Desempenho e Impacto no CI
- Muitos ficam impressionados com os ganhos de velocidade reportados de 50–100x em comparação com o ESLint; um caso: 75 minutos em mais de 40 workers de CI → ~10 segundos em um único worker.
- Alguns argumentam que isso é transformador para monorepos grandes e para linting de repositório completo no CI; outros dizem que lint raramente é o gargalo e preferem linting parcial (apenas arquivos alterados) ou abordagens incrementais.
- Há debate sobre se o linting de repositório completo é necessário; regras sensíveis a tipos e entre arquivos são citadas como razões pelas quais o linting parcial é difícil.
Regras, Personalização e Compatibilidade com o Ecossistema
- Grande obstáculo para a adoção: falta de paridade com as centenas de regras do ESLint e com seu rico ecossistema de plugins (TypeScript, React, regras de importação, “rules of hooks”, etc.).
- Vários dependem fortemente de regras personalizadas do ESLint como “codemods contínuos” e análise estática específica do projeto, então veem o ESLint como insubstituível até que existam equivalentes.
- O suporte planejado do Oxlint para regras personalizadas via consultas Trustfall e YAML é visto como promissor, mas ainda inicial.
DX, Configuração e Fluxo de Trabalho
- A configuração do ESLint é amplamente descrita como complexa e frágil, especialmente com TypeScript/React e múltiplos conjuntos de regras sobrepostos.
- Alguns elogiam ferramentas que “simplesmente funcionam” com configuração mínima (Ruff para Python, o linter/formatador встроído do Deno, convenções de Go/Rust) e gostariam de algo parecido em JS/TS.
- Outros argumentam que a configuração inicial do lint é um custo único e que configurações estáveis podem durar anos.
Comparações com Outras Ferramentas
- Comparações frequentes com Ruff (Python), Biome (ex-Rome), Bun, Deno, dprint, Pyright, mypy, o próprio TypeScript.
- A questão de por que escolher o oxlint em vez do Biome; uma resposta: foco mais forte na compatibilidade com o ESLint, embora o Biome aparentemente implemente mais regras do ESLint hoje.
Reescritas em Rust e Escolha de Linguagem
- O tópico situa o oxlint em uma tendência mais ampla de reescrever ferramentas de JS em भाषagens compiladas (Rust, Go, Zig).
- Defensores: enormes ganhos de velocidade, melhor organização de memória para ASTs, boa distribuição por meio de binários únicos, Rust mais acessível que C/C++.
- Críticos: problemas de desempenho podem mascarar problemas mais profundos de complexidade/dívida técnica; usar uma linguagem não-JS para ferramentas de JS pode reduzir o número de colaboradores e arriscar a sustentabilidade no longo prazo.
Filosofia do Linting
- Há discordância sobre se linting deve ser leve e apenas de estilo ou se deve ser uma análise estática profunda, central ao desenvolvimento.
- Alguns veem linting pesado como excesso de escopo e carga de manutenção; outros enxergam uma análise estática forte e específica do projeto como um grande “superpoder” de produtividade e qualidade.