Angular ganha compilador em Rust que promete builds frios até 3x mais rápidos

Por que o Angular precisou reescrever o compilador

O time do Angular↳Angular30 conteúdosCriando Micro Frontends Angular com Native FederationDev (Back & Front) · mar 2026Angular v21 e o Fim da Cobertura de Testes Exclusivamente em TypeScript: Por Que Precisamos Repensar os Testes de ComponentesDev (Back & Front) · jan 2026Angular 8 é lançado com builder APIs e suporte web workerDev (Back & Front) · mai 2019Ver tudo em Dev (Back & Front) →, em pessoas como Alex Rickabaugh e Mark Techson, publicou no fim de setembro de 2026 um post no blog oficial detalhando o Angular Preprocessor (ngp), uma reescrita parcial do compilador em Rust. O motivo não foi só velocidade: foi sobrevivência. Pouco antes, a Microsoft lançou o TypeScript 7.0, cuja reescrita em Go removeu a API ts.Transformer, usada pelo compilador atual do Angular (ngc) para transformar decorators como @Component e @Pipe em instruções de runtime.

Sem equivalente dessa API no lado Go, e com a travessia entre JavaScript e Go a cada arquivo sendo proibitivamente lenta, o Angular não tinha como simplesmente seguir migrando junto com o TypeScript. A saída encontrada foi desacoplar a compilação das APIs internas do TypeScript e reconstruir o estágio de análise sobre o Oxc, o toolchain em Rust da VoidZero que já roda por baixo do Vite. Em um post no X, o time definiu o trabalho como reescrita parcial, não um recomeço do zero.

Como o ngp funciona por dentro

O novo pipeline roda em três estágios bem separados, o que muda a forma como o compilador conversa com o resto da toolchain:

1. Um frontend em Rust, construído sobre o Oxc, analisa os arquivos em paralelo para descobrir declarações Angular e resolver metadados.
2. O compilador de templates em TypeScript, ainda mantido, emite dois artefatos: um arquivo de runtime com o componente transformado e um arquivo .ngtypecheck.ts contendo o Type Check Block (TCB) usado na checagem de tipos dos templates.
3. Uma ferramenta downstream, à escolha do projeto (tsgo, tsrs, esbuild ou Rolldown), assume a checagem de tipos e a emissão final de JavaScript, de forma independente do estágio anterior.

O grosso do ngp chegou ao repositório em 8 de outubro de 2026, em um único commit com mais de 370 mil linhas, das quais cerca de 56 mil em Rust.

Os números que apareceram nos primeiros testes

Cédric Exbrayat, da Ninja Squad, rodou o beta em três projetos reais, de 15 a 1.714 componentes, e mediu o que ficou de concreto até agora: ganho de 2x a 3x em builds frios, com o uso de memória no maior projeto caindo de 2,8 GB para 1,4 GB. A combinação mais rápida foi ngp com tsrs e Rolldown; tsgo e esbuild ficaram só marginalmente atrás disso.

Isso já é muito promissor, e certamente há mais ganhos a extrair quando o time focar em otimização de performance.

Cédric Exbrayat, Ninja SquadThis is already very promising, and there are certainly further gains to be made when the team focuses on performance optimization.

Christopher Holder, da push-based.io, testou um caminho diferente: escreveu o vite-plugin-ngp para compilar arquivos Angular sob demanda, dentro do dev server. No código do Super Productivity, com 252 componentes, o servidor de desenvolvimento chegou à primeira página em 10,5 segundos contra 17,4 segundos do ng serve, e edições de template passaram a aplicar em 112 milissegundos em vez de um reload completo de 2,6 segundos. Em uma aplicação gerada com 5.000 componentes, a diferença chegou a 1,6 segundo contra 28,4 segundos.

Holder foi direto sobre a maturidade do que construiu: nas palavras dele, o plugin "é um protótipo sobre um protótipo" (no original, em inglês, "a prototype on a prototype"), e está fixado na versão 22.3.0-next.2.

A reação da comunidade e o que vem da VoidZero

No Reddit, a recepção ao anúncio foi em boa parte entusiasmada:

Li o artigo inteiro. Impressionante. O time do Angular superou minhas expectativas!

Comentário em thread do Reddit sobre o lançamento do ngpRead the whole article. Impressive. The Angular team surpassed my expectations!

Vale lembrar que o Angular não é o primeiro a testar essa rota. A própria VoidZero mantém um compilador experimental Angular sobre o Oxc, coberto pelo InfoQ em abril de 2026, que chegou a reportar uma melhora de cerca de 97% em cargas de trabalho mais estreitas. Hoje esse projeto é descrito como "ativamente buscando mantenedores". O time do Angular confirmou que o trabalho da VoidZero influenciou a arquitetura do ngp e que os dois grupos vêm colaborando, com o ngp assumindo o papel de caminho oficial daqui pra frente.

O que muda na prática para quem desenvolve em Angular

Nada disso está pronto para produção ainda, e essa é a informação mais importante para quem gerencia pipeline de CI hoje. A adoção do ngp deve chegar em uma versão menor do Angular 22, e só depois que o TypeScript 7.1 restaurar uma API de compilador compatível. Até lá, builds de produção devem continuar no ngc atual.

Quem está em versões mais antigas do Angular também precisa resolver uma etapa anterior: o guia oficial de atualização recomenda primeiro chegar à versão 20 ou mais recente antes de pensar em ngp. Para times brasileiros com monorepos grandes (bancos, varejo, telecom costumam ter aplicações Angular com centenas de componentes), os números de memória chamam atenção tanto quanto o tempo de build: cortar de 2,8 GB para 1,4 GB em um projeto grande pode significar rodar CI em runners menores, ou parar de estourar limite de memória em pipeline compartilhado.

Para quem quer só curiosidade, o vite-plugin-ngp de Holder é hoje a forma mais acessível de sentir o ganho de hot reload em ambiente de desenvolvimento, mesmo sabendo que é protótipo sobre protótipo e que a versão pinada pode mudar sem aviso. Vale testar num branch isolado, sem expectativa de estabilidade, e acompanhar o blog do Angular e o repositório do ngp para saber quando a combinação com TypeScript 7.1 libera o caminho para produção.

Fonte: InfoQ