Angular 22: o que mudou de verdade, e o que fazer num app em produção

O que o Angular 22 é de verdade#

O Angular 22 chegou em 3 de junho de 2026. Bate o olho na lista de features e parece coisa demais. Mas olha com cabeça de tech lead que tem app em produção e tudo se separa em dois grupos: o que era experimento e virou estável, e os defaults que mudaram.

O que virou estável é opcional. Signal Forms, as APIs assíncronas resource e httpResource e o Angular Aria agora são estáveis, mas ninguém te obriga a usar. Já as mudanças de default, não: OnPush, strictTemplates, o backend Fetch do HttpClient e o incremental hydration passam a valer a não ser que você diga o contrário, e o ng update escreve migrações no seu código pra segurar o comportamento antigo.

Então a pergunta que importa no upgrade não é "o que tem de novo". É "quais migrações a CLI acabou de escrever no meu app, e quais eu quero mesmo manter". O resto do guia é responder isso, área por área.

A mudança que mexe com todo componente: OnPush por padrão#

Pra um app que já existe, o que pega é uma linha no changelog: a estratégia padrão de change detection agora é OnPush. Um componente que nunca definiu changeDetection rodava eager, checando a cada tick. No v22 esse mesmo componente é OnPush.

O ng update não te deixa na mão. Ele escreve changeDetection: ChangeDetectionStrategy.Eager nos seus componentes pra nada mudar em runtime. É a jogada segura, e também uma lista de tarefas: cada Eager que ele adiciona é um componente que dependia da checagem eager, e um candidato a virar OnPush de verdade com calma.

O que eu faria: deixa os componentes novos serem OnPush, porque o padrão novo é o certo, e trata os Eager que a migração adicionou como backlog, não como veredito. Os componentes que quebram quando você tira o Eager são os que mudam estado do template sem avisar o Angular, o mesmo tipo de código que aparece quando um app vira zoneless. O v22 só deixou a pergunta inevitável.

// v22: agora este componente é OnPush por padrão. Sem linha de strategy.
@Component({ selector: 'app-badge', template: '{{ count() }}' })
export class BadgeComponent {
  count = signal(0);   // a escrita do signal marca a view OnPush como suja, então beleza
}

// O que o ng update põe nos seus componentes ANTIGOS pra preservar o eager:
@Component({
  selector: 'app-legacy',
  changeDetection: ChangeDetectionStrategy.Eager,   // adicionado pela migração
  template: '...',
})
export class LegacyComponent {}

As estabilizações: o que virou estável, e se vale adotar#

Três coisas saíram do experimental no v22, e a resposta honesta pra "devo adotar" muda de uma pra outra.

Signal Forms é o destaque. Era developer preview no v21, e ser estável muda a conta: código novo já pode usar, e o v22 fechou as lacunas que me deixavam cauteloso antes (validators de data, validação async com debounce, getError com narrowing de tipo). Eu mostro como eu adotaria hoje, e o resumo é: usa num form novo, mas não sai reescrevendo reactive form que funciona só por isso.

As APIs resource e httpResource são a camada de dados dos async signals, e também são estáveis. Isso encerra a cautela do Estado HTTP sem transformar tudo em Signals: o httpResource não é mais um experimento pra isolar, é ferramenta que você pode pôr numa leitura de verdade. O Angular Aria também virou estável junto, e agora funciona com Signal Forms, o que faz controle de form acessível deixar de ser um trabalho de construir na mão.

Os testes também andaram, e a maior parte a seu favor#

Se você migrou testes pro Vitest, o v22 transformou dois workarounds em features suportadas. O zone.js/plugins/vitest-patch que mantém o fakeAsync vivo agora é o caminho documentado, não um truque. E há schematics novos: uma migração migrate-karma-to-vitest faz a troca de runner, e o refactor-jasmine-vitest ganhou um flag --fake-async que reescreve testes de tempo pra timers nativos do Vitest por você.

Isso não aposenta o trabalho, só muda o formato. O schematic converte os casos mecânicos, mas os testes com Promise na cadeia ainda precisam de review, e você ainda tem que decidir se vale migrar uma suíte. O piso ficou mais alto do que estava um release atrás.

# Converte specs Jasmine pra Vitest, com timers nativos pros testes de fakeAsync:
ng generate @schematics/angular:refactor-jasmine-vitest --fake-async --include=src/app

As viradas de default menores que pegam no upgrade#

Um punhado de mudanças mais discretas aparece como surpresa se você não souber delas. O HttpClient agora usa o backend Fetch por padrão e o withFetch() está deprecado, com a migração tirando ele. O strictTemplates vem ligado, então templates que passavam no type-check de forma frouxa podem começar a falhar o build. Incremental hydration é o padrão pra apps SSR. E a toolchain andou: TypeScript 6 é obrigatório, o Node 20 saiu e o Node 26 entrou.

Nenhuma é difícil, mas cada uma é um ponto onde um ng update limpo ainda te deixa uma decisão manual. O router tem uma sem migração nenhuma: paramsInheritanceStrategy agora tem default 'always', o que pode mudar o que uma rota filha lê dos params.

O que eu faria essa semana#

O upgrade em si é ng update @angular/core @angular/cli, e aí o trabalho real é ler o que ele escreveu. Rode as migrações, e revise o diff com duas perguntas: quais adições de Eager no change detection eu quero manter, e quais remoções de deprecação eu aceito.

Depois do upgrade mecânico, as decisões de adoção são a parte interessante, e são o mesmo filtro disciplinado de sempre: adote o que é seguro, teste o que não é, deixe código estável quieto. Signal Forms e httpResource estáveis os movem da coluna de spike pra coluna de adotar-em-código-novo, que é exatamente o tipo de mudança que um plano de modernização deve absorver sem virar reescrita.

O v22 recompensa quem já estava migrando pra signals aos poucos, e o padrão OnPush sobe sem alarde a régua de higiene de change detection pro resto. É um release pra encarar com calma e critério.