Rspack 2.3: parser SWC Next, cache por loader e menos memória no build

Rspack 2.3: parser SWC Next, cache por loader e menos memória no build

O Rspack 2.3 foi publicado em 29 de outubro de 2026 e, pela primeira vez em muito tempo, a novidade principal de um bundler não é "build mais rápido", mas troca de parser . A versão integra o SWC Next, o próximo major do compilador do time do SWC, desenvolvido em conjunto com o time do Rstack (a empresa por trás do Rspack, do Rsbuild e do Rslib).

Os números divulgados pela própria equipe: builds de 5% a 20% mais rápidos, até 27,4% menos pico de memória em um benchmark de aplicação real, menos código duplicado entre chunks e cerca de 79% menos uso de disco com a nova implementação de cache. Tudo isso são medições de fornecedor — trate como hipótese a validar no seu repositório, não como fato consumado.

Por que isso importa para quem escreve código: build é o principal gargalo de feedback em monorepo de médio porte, e memória de build é o que define o tamanho (e o custo) do runner de CI. Um corte de 27% no pico de RSS pode ser a diferença entre 8 GB e 16 GB de máquina em cada job, multiplicado por dezenas de execuções por dia.

SWC Next: AST plano, inspirado no Yuku

O SWC Next não é uma iteração do SWC atual. A arquitetura do parser foi inspirada no Yuku , compilador de TypeScript escrito em Zig, e gira em torno de um AST plano e baseado em ESTree , em vez da árvore profundamente aninhada do SWC clássico. As alegações do anúncio são de até 3x de ganho no parse nativo e até 10x quando o parser é chamado pela API JavaScript.

Esse segundo número é o mais interessante estrategicamente. Historicamente, transformações customizadas escritas em JavaScript pagam um pedágio alto ao cruzar a fronteira Rust↔JS e ao percorrer o AST. Um AST plano, no formato ESTree — o mesmo que ESLint, Babel e Acorn usam —, reduz esse atrito e abre caminho para plugins escritos em JS com desempenho aceitável.

Vale o alerta público do Rob Palmer, da equipe do TypeScript: os números de benchmark "devem ser lidos com cautela até os bugs serem corrigidos". O parser é novo e, como todo parser novo, tem casos de borda com sintaxe exótica, decorators, JSX em arquivos .mts e TypeScript em estágios avançados de proposta.

O que muda no arquivo de configuração

Na prática, quase nada. A configuração de um projeto que já roda Rspack 2.x continua válida: a integração do parser é interna. Um rspack.config.mjs mínimo continua assim:

O risco não está no rspack.config , está no que consome o AST: loaders e plugins da comunidade que dependiam de detalhes internos do SWC, regras de lint que compartilham o parser, ferramentas que inspecionam o output do compilador. Se o seu pipeline tem plugin próprio escrito em Rust ou um loader que faz análise sintática, este é o ponto de atenção número um.

Cache por loader, disco e o CI

A nova implementação de cache é experimental e é o item que mais muda a operação: ela permite cachear o resultado de transformação por loader , em vez de descartar tudo quando qualquer entrada do módulo muda. O efeito cai direto no disco — cerca de 79% menos espaço segundo o anúncio — e no tempo de rebuild em CI que restaura cache entre jobs.

Confirme o nome exato da opção no guia de configuração da sua versão: as opções de cache ganharam granularidade no 2.2 e o formato pode variar entre minors.

O jeito certo de avaliar é medir tempo e memória, no mesmo runner, com e sem cache:

Rode duas vezes em cada cenário (frio e quente) e compare. Sem esse par de números, você está trocando uma versão com base em slide.

SplitChunks: menos duplicação, mais estabilidade de hash

As otimizações de splitChunks reduzem código duplicado entre chunks — em bibliotecas grandes compartilhadas por rotas, isso aparece como queda real de bytes e não como inflação de estatística. O efeito colateral é o de sempre: mudanças de particionamento alteram hashes de arquivos e invalidam cache de CDN. Se o seu deploy depende de contenthash estável para servir assets, planeje a troca para uma janela de menor tráfego, e não na véspera de Black Friday.

Para comparar antes e depois sem adivinhação, use o Rsdoctor — que também recebeu atualização no mesmo ciclo, junto com Rsbuild, Rslib, Rstest e Rspress. Ele mostra módulos duplicados, tamanho por chunk e o impacto de cada mudança de configuração.

Riscos e armadilhas

Cache experimental com transformação dependente de ambiente. Se um loader usa process.env ou variável injetada para gerar código, a chave de cache pode não contemplar isso e você reaproveita saída de outro ambiente. Valide em preview antes de produção.

Benchmark de fornecedor é benchmark de fornecedor. 27,4% de redução de memória foi medido em um repositório específico, com um conjunto específico de loaders. Em projeto com muitos plugins JS, o ganho pode ser bem menor — ou negativo.

Parser novo, casos de borda novos. Se o seu código usa sintaxe pouco comum, o teste de compatibilidade é a suíte de testes de verdade, rodando sobre o build de produção, não o dev server .

Efeito no CI maior que no dev server. Dev server ganha em latência; CI ganha em memória e em reaproveitamento de cache. São ganhos diferentes e exigem métricas diferentes.

Custo de adoção baixo, mas não zero. É um update de dependência; o trabalho está em medir, ajustar limite de memória do runner e revalidar cache.

Em times que mantêm stacks heterogêneas — Angular ou React no front, Node.js, .NET e Python no back, com bancos relacionais e uma esteira de CI única —, trocar o bundler mexe em pipeline compartilhado, não em um projeto isolado. É o tipo de decisão que a Maquinaweb costuma tratar como mudança de plataforma: primeiro instrumentar, depois migrar por repositório, com rollback definido.

Recomendação prática

Atualize, mas meça antes de comemorar. O roteiro que funciona em uma tarde: faça uma branch com @rspack/core@2.3 , rode build frio e quente três vezes, capture tempo e pico de RSS com /usr/bin/time -v , compare o relatório do Rsdoctor e só então decida se o cache experimental entra. Se o ganho aparecer, ajuste o tamanho do runner no CI — a economia real está lá, não no cronômetro do seu notebook. Se você depende de plugins que tocam o AST, reserve uma rodada de testes de compatibilidade.

Se o seu time está avaliando migrar de webpack para Rspack, ou revisar o custo da esteira de build, vale conversar com o time da Maquinaweb para discutir arquitetura, migração de stack e desenvolvimento sob medida com quem faz isso no dia a dia.

Fontes