Uma análise do JavaScript Oxidation Compiler

O Oxc, o JavaScript Oxidation Compiler, é um conjunto de ferramentas de alto desempenho para JavaScript e TypeScript escritas em Rust, construídas sobre um parser e uma AST compartilhados, de modo que o linter, o formatador, o transformer, o minificador e o resolver nunca precisem reprocessar seu código de forma independente.

Se você já iniciou uma execução de lint em um monorepo grande, saiu para tomar um café e voltou para encontrá-la ainda em andamento, você já sabe por que uma reescrita em Rust do toolchain JavaScript recebeu tanta atenção. Essa espera, multiplicada por cada desenvolvedor e cada job de CI, é a maior parte do motivo pelo qual o Oxc existe.

Ele é a camada de compilação por baixo do toolchain da VoidZero e, a partir do Vite 8, é a engrenagem que faz o trabalho real de linguagem dentro de todo build do Vite.

Se seu pipeline com ESLint/Babel/Prettier está lento e você vem acompanhando a onda de ferramentas em Rust (esbuild, SWC, Biome, Oxc), a pergunta prática não é “o Oxc é rápido?”. É “quais peças estão prontas para produção hoje e como elas se encaixam no que eu já executo?”. Este artigo responde a isso: o que é o Oxc, o que há nele, o que você pode adotar com segurança agora e como ele se posiciona frente às alternativas.

O que é o Oxc, o JavaScript Oxidation Compiler?

O Oxc é um conjunto de ferramentas nativas em Rust para JavaScript e TypeScript que compartilham um único parser e uma única AST, de modo que o comportamento permanece consistente e nenhuma ferramenta duplica o trabalho de parsing. O nome é uma referência ao Rust: rust (“ferrugem”, em inglês) é aquilo em que o metal se transforma quando oxida. Velocidade, aqui, é tratada como algo que o projeto precisa entregar, e não como um efeito colateral agradável, partindo do raciocínio de que um linter mais rápido significa um ciclo de edição e verificação mais curto localmente e uma conta de CI menor.

A razão pela qual o Oxc importa além de suas próprias CLIs é que ele é o compilador por baixo da stack moderna do Vite. O Rolldown é um bundler em Rust, e ele delega o trabalho de nível de linguagem, parsing e minificação incluídos, ao Oxc. A partir do Vite 8, as três camadas são construídas por equipes trabalhando em sintonia: o Vite como ferramenta de build, o Rolldown como bundler e o Oxc como o compilador por baixo de ambos. Assim, mesmo desenvolvedores que nunca instalaram um pacote do Oxc estão executando seu parser e seu transformer em cada build.

Há também um contexto de propriedade que vale conhecer antes de apostar um pipeline nisso. Em 4 de junho de 2026, a Cloudflare anunciou que havia comprado a VoidZero, a empresa de código aberto que mantém o Vite e as ferramentas ao seu redor, incluindo o Oxc. Ambos os lados afirmam que os projetos continuam open source e neutros em relação a fornecedores, com Vite, Vitest, Rolldown, Oxc e Vite+ todos permanecendo sob licenças MIT, e a Cloudflare destinou US$ 1 milhão a um fundo independente para mantenedores e contribuidores do Vite. A própria VoidZero foi criada em 2023 pelo criador do Vue.js, Evan You.

Os componentes e o que cada um substitui

O Oxc é distribuído como peças separadas e combináveis, então você pode adotar uma sem as demais. Cada uma tem como alvo um incumbente lento baseado em JavaScript:

O parser é a âncora. Todos os outros componentes leem sua saída, e é por isso que o Oxc pode se apresentar como um único toolchain em vez de seis ferramentas que por coincidência foram escritas em Rust.

Por que o Oxc é rápido?

A velocidade do Oxc vem da arquitetura, não de micro-otimizações. Três escolhas fazem a maior parte do trabalho. Primeiro, é Rust compilado em vez de JavaScript interpretado, então os caminhos críticos rodam em velocidade nativa e evitam pausas de coleta de lixo. Segundo, todas as ferramentas operam sobre uma AST compartilhada, eliminando o reparsing redundante que ocorre quando ESLint, Prettier e Babel processam separadamente o mesmo arquivo. Terceiro, os nós da AST são alocados em uma arena de memória, permitindo limpeza em massa de baixo custo, e a análise é paralelizada entre os núcleos da CPU.

O ganho é mensurado, e os números são benchmarks do próprio projeto, então trate-os como tal. A VoidZero relata o Oxlint como 50 a 100 vezes mais rápido que o ESLint, o Oxfmt com 30× ou mais a taxa de processamento do Prettier e algo entre 2× e 3× a do Biome em uma primeira execução sem cache, e o Rolldown com builds até 10 a 30 vezes mais rápidos que o Rollup. O número relativo ao Biome é uma faixa porque as próprias fontes do Oxc divergem: a documentação do formatador cita 2×, o anúncio do beta cita 3×. Benchmarks diferentes em máquinas diferentes chegarão a resultados diferentes; a magnitude do ganho é real, o multiplicador exato é marketing até que você o execute no seu repositório.

O que já está pronto para produção no Oxc hoje?

A maturidade no Oxc depende de como você consome cada ferramenta. O Oxlint e o parser são genuinamente prontos para produção de forma independente; o transformer e o minificador estão pré-1.0 como CLIs, mas já rodam em produção dentro do Rolldown e do Vite 8; o Oxfmt está em beta.

O Oxlint é o destaque claro. Ele lançou uma versão 1.0 estável em junho de 2025, com Shopify, Airbnb e Mercedes-Benz citadas nas notas de lançamento como usuárias em produção, e agora está na linha 1.x com 844 regras nativas. O Oxlint também faz linting com reconhecimento de tipos: o backend tsgolint conecta o próprio sistema de tipos do TypeScript à CLI e ao formato de configuração do Oxlint, e cobre 59 das 61 regras com reconhecimento de tipos que o typescript-eslint oferece. As ressalvas honestas: é opt-in, requer o pacote separado oxlint-tsgolint instalado ao lado do Oxlint, e os números de versão desse pacote acompanham a release do TypeScript contra a qual ele é compilado, e não a do Oxlint, então os dois evoluem em cronogramas diferentes. A equipe também fechou a porta para regras fora do conjunto do typescript-eslint enquanto trabalha em cobertura e desempenho, o que descarta regras personalizadas com reconhecimento de tipos por ora.

Não interprete “o transformer e o minificador estão pré-1.0” como “não estão prontos para produção”. Ambos já rodam sob todos os builds do Vite 8. O guia de migração do Vite 8 detalha a divisão de trabalho: o Oxc assumiu a transformação de JavaScript e a minificação de JavaScript do esbuild, enquanto o Lightning CSS se tornou o padrão para minificar CSS. O Oxfmt, por sua vez, passou de alpha para beta e agora passa por toda a suíte de conformidade de JavaScript e TypeScript do Prettier, mas o npm ainda o rotula como Beta, então ele é um piloto, não uma substituição integral do Prettier ainda.

Como o Oxc se compara ao SWC e ao Biome

O erro de comparação mais comum é colocar o Oxc contra o SWC em termos de velocidade. Eles ocupam camadas diferentes. O SWC é uma plataforma de compilação que frameworks incorporam: o Next.js é dono de sua integração com o SWC, e você não deveria arrancá-la em busca de um gráfico de benchmark. O transformer do Oxc compete com o SWC e o Babel, mas o SWC não tem linter nem formatador de primeira parte, então o Oxlint compete com o ESLint e o Biome, não com o SWC. O Biome é o rival mais próximo: uma ferramenta em Rust que faz lint e formatação em um único binário, enquanto o Oxc mantém Oxlint e Oxfmt como peças separadas e combináveis.

Diante disso, a jogada pragmática é adotar o Oxlint agora e observar o resto. Execute-o como uma primeira passada rápida no CI, mantendo o ESLint para as regras e plugins que ele ainda não cobre:

{
  "scripts": {
    "lint:fast": "oxlint",
    "lint": "oxlint && eslint ."
  }
}

Para reduzir a sobreposição, a documentação aponta para o @oxlint/migrate para traduzir uma configuração existente do ESLint, além do eslint-plugin-oxlint para desativar regras que o Oxlint já trata. Isso lhe dá o ganho de velocidade no caminho rápido sem abrir mão da cobertura do ESLint na execução completa.

O Oxc deixou de ser um “projeto promissor em Rust” e passou a ser infraestrutura da qual milhões de builds já dependem, mas não de maneira uniforme em toda a sua superfície. Comece pelo Oxlint (estável, rápido e de baixo risco ao lado do seu linter atual), teste o Oxfmt em uma branch para verificar o diff, e deixe que o transformer e o minificador cheguem até você por meio do Vite 8, em vez de adotá-los isoladamente. Reavalie as peças pré-1.0 conforme elas se formam; a direção do movimento é clara o bastante para se planejar em torno dela.

Perguntas frequentes

Posso executar o Oxlint e o ESLint juntos, ou preciso escolher um?

Você pode executar ambos, e executar ambos é o caminho de adoção recomendado. Use o Oxlint como uma primeira passada rápida no CI e mantenha o ESLint para as regras e plugins que o Oxlint ainda não cobre. A documentação do Oxc aponta para o '@oxlint/migrate' para traduzir uma configuração existente do ESLint e para o 'eslint-plugin-oxlint' para desativar regras do ESLint que o Oxlint já trata, o que elimina trabalho duplicado enquanto você executa os dois linters.

O Oxc substitui o SWC, e devo remover o SWC do Next.js para usá-lo?

Não. O transformer do Oxc compete com o SWC e o Babel, mas você não deve arrancar o SWC de um framework que o incorpora, como o Next.js, em busca de um benchmark. O SWC é uma plataforma de compilação que os frameworks mantêm internamente, e o SWC não tem linter nem formatador de primeira parte, então o Oxlint compete com o ESLint e o Biome, e não com o SWC. A superfície segura de adoção é o Oxlint, não a troca do compilador embutido de um framework.

Qual é a diferença entre o Oxc e o Biome?

O Biome é um único binário em Rust que faz tanto linting quanto formatação, enquanto o Oxc mantém seu linter (Oxlint) e seu formatador (Oxfmt) como peças separadas e combináveis que você pode adotar de forma independente. O Oxc também é mais abrangente: inclui um parser, um transformer, um minificador e um resolver que dão suporte ao Rolldown e ao Vite 8, enquanto o Biome foca na camada de lint e formatação. Em uma execução inicial sem cache, os benchmarks da VoidZero apontam o Oxfmt como aproximadamente 2 a 3 vezes mais rápido que o Biome; a documentação do Oxfmt e o anúncio do beta citam números diferentes para essa comparação.

A aquisição da VoidZero pela Cloudflare muda se o Oxc continua open source?

Não. A Cloudflare adquiriu a VoidZero em 4 de junho de 2026, e ambas as empresas afirmam que os projetos permanecem open source e neutros em relação a fornecedores. Vite, Vitest, Rolldown, Oxc e Vite+ continuam sob licenças MIT, e a Cloudflare comprometeu 1 milhão de dólares a um novo fundo independente do ecossistema Vite para mantenedores e contribuidores sem vínculo com a VoidZero ou a Cloudflare. O licenciamento MIT significa que forks e usos existentes não são afetados, independentemente da propriedade.