Angular ngp: compilador em Rust entra em beta, corta build frio e abre o caminho para o TypeScript 7

Angular ngp: o compilador em Rust entrou em beta

O time do Angular colocou em beta o ngp (Angular Preprocessor) , um novo pipeline de compilação que reescreve a etapa de análise em Rust, sobre o Oxc — o mesmo toolchain Rust usado pelo Vite, da VoidZero. O anúncio foi feito por Alex Rickabaugh e Mark Techson no blog do time em setembro, mas só nos últimos dias apareceram os primeiros números públicos de benchmark e a discussão sobre adoção, com cobertura do InfoQ e do iMasters em 11 de novembro.

A motivação não é estética: o TypeScript 7.0, lançado neste ciclo, é um port do compilador para Go e removeu a API ts.Transformer . O compilador do Angular ( ngc ) era essencialmente um wrapper em volta do tsc que plugava a transformação de templates dentro do pipeline do TypeScript. Sem esse gancho, o Angular ficaria preso no TypeScript 6 enquanto o resto do ecossistema migra. O ngp é a resposta: desacoplar a compilação de templates da API do TypeScript.

Um detalhe importante para não confundir assuntos: a volta da API programática no beta do TypeScript 7.1 não resolve o caso do Angular — o contrato interno que o ngc usava não é o mesmo, e o time preferiu não reconstruir a dependência. A leitura é minha, mas os fatos apontam para uma decisão estrutural, não um contorno temporário.

Como o ngp funciona por dentro

O desenho tem três estágios:

Frontend em Rust (Oxc). Lê os arquivos em paralelo, faz o parsing e descobre declarações do Angular — componentes, diretivas, pipes — sem esperar o tsc terminar de montar o programa.

Transformação de templates. A análise de template, que antes rodava como um transformer do TypeScript, passa a acontecer fora do compilador de tipos, com o resultado devolvido ao pipeline.

Emit. A geração de código final continua coordenada com o restante da build, mas o Angular deixa de depender de APIs internas do tsc para chegar lá.

O commit que trouxe o grosso do compilador passa de 370 mil linhas, com cerca de 56 mil de Rust, segundo a análise do Ninja Squad. É um projeto grande, e vale entender o que ele não muda: código de aplicação em Angular — component, template, service, signal — continua igual. O que muda é a ferramenta que transforma isso em JavaScript.

Os números e o que eles realmente dizem

Os benchmarks divulgados apontam builds frios de 2x a 3x mais rápidos , com uso de memória menor e feedback mais rápido no dev server. Para comparação de escala: os benchmarks do próprio TypeScript 7 mostram 8x a 12x em build completo no código do VS Code (125,7 s para 10,6 s) e no Sentry (139,8 s para 15,7 s).

Duas ressalvas que costumam passar batido:

Build frio é a métrica mais generosa. Em build incremental — o ciclo real de quem desenvolve — o ganho tende a ser menor, porque o gargalo passa a ser invalidação de cache e não parsing.

Um build frio de 2x a 3x em CI roda uma vez por pipeline; o dev server roda dezenas de vezes por dia. Antes de vender economia para a gestão, meça em monorepo com a sua quantidade de bibliotecas — é onde a diferença entre análise paralela e serial aparece.

Onde o risco mora: ferramentas, não templates

Aplicação comum tem pouco a fazer. O problema está na camada de tooling que se acopla ao compilador:

Qualquer coisa parecida com isso — codemods internos, builders customizados, esquemas que leem @angular/compiler-cli , regras de lint que dependem do TypeChecker dentro de template — é o primeiro lugar onde a migração quebra. O caminho é reescrever na API nova ou migrar para hooks na camada do Oxc/bundler, e isso é trabalho de engenharia, não de atualização de dependência.

Outros pontos de atenção:

Versões casadas. @angular/* , ng-packagr e o toolchain precisam andar juntos; misturar um pacote em beta derruba o build de bibliotecas com erro pouco descritivo.

Cache de CI inválido. Trocar o compilador invalida cache de build — o primeiro pipeline depois da mudança vai parecer um retrocesso.

SSR e prerender. O pipeline de build de servidor tem outros pontos de extensão; teste separado do build de browser.

Produção. A orientação do time é manter build de produção no ngc até o ngp entrar em uma minor do Angular 22.

O que eu recomendo fazer agora

Para times que rodam Angular em produção, a sequência que faz sentido é:

Trave o TypeScript na versão atual e mapeie a dependência: grep -r "compiler-cli\|ts.Transformer\|createProgram" --include=*.ts no repositório de ferramentas.

Meça baseline com o pipeline real (build frio e rebuild incremental, com e sem cache) antes de qualquer teste com o beta.

Teste o ngp em branch isolada , com build de produção e SSR, não só no dev server.

Não combine a migração do compilador com a migração para TypeScript 7 na mesma janela. Duas variáveis independentes numa janela só transforma um bug em investigação de dias.

Na Maquinaweb, projetos Angular convivem com back-ends em Python, Node.js e .NET, então a decisão de subir TypeScript nunca é local — ela afeta pipeline, lint, bibliotecas compartilhadas e times que entregam em ritmos diferentes. É esse tipo de decisão de engenharia, e não o release em si, que define o custo real.

Fechamento

O ngp é a notícia mais relevante do ecossistema Angular neste ciclo, mas é beta de compilador: ganho real de velocidade em build frio, risco real em tooling. Para quem tem um app médio e sem customizações de build, o caminho é esperar a minor estável e acompanhar os benchmarks da comunidade. Para quem mantém bibliotecas, builders ou ferramentas internas acopladas ao compiler-cli , começar o inventário agora evita uma migração forçada depois.

Se o seu time precisa decidir entre migrar o compilador, subir de versão do TypeScript ou reestruturar o pipeline de build de um projeto Angular sob medida, o time da Maquinaweb pode ajudar a mapear o impacto e desenhar o plano de migração.

Fontes