Angular moderno para times em produção

A decisão que você realmente toma no PR review#

Cinco Angular majors caíram entre v16 (maio/2023) e v21 (novembro/2025), conforme a referência oficial de releases. Essa cadência funciona quando o time tem referência escrita sobre o que adotar, testar em spike, ou explicitamente esperar. Sem essa referência, toda PR de modernização reabre o mesmo debate.

Você é quem aprova as PRs de modernização num time Angular 16-21 em produção (tech lead, arquiteto técnico, ou a sênior que o time consulta). Uma PR cai na sua fila: feature nova usando Signals pra estado local. Você tem trinta segundos. Aprova, devolve ou escala?

Boa parte do ruído de modernização vive nesses trinta segundos. O framework não para de soltar versão. O time não para de propor adoção. Você aprova ou empurra de volta sem referência escrita. Três trimestres depois, metade do código parece Angular 16 e a outra metade parece Angular 21, e ninguém sabe explicar o split.

Três documentos que o time concorda antes de qualquer proposta de modernização entrar em discussão absorvem boa parte dessa pressão. A lista de padrões aprovados como default. A lista de padrões em spike. A lista de padrões explicitamente esperando.

Três listas que o time deve manter#

Cada lista responde a uma pergunta de review diferente.

O que entra em cada lista#

A primeira lista é o 'sim'. Componentes novos vão standalone, estado local vai pra Signals, control flow usa @if/@for/@switch, injeção de dependência usa inject. Codificado no linter pra PR review não re-discutir a decisão.

RxJS continua default pra streams genuinamente assíncronos (autocomplete com debounce, WebSocket, polling, cancelamento). Signals substitui estado local que antes vivia em BehaviorSubject. Os dois não competem; eles respondem perguntas diferentes.

A segunda lista é o 'talvez, em branch'. Zoneless em app existente (stable desde v20.2, default em projetos novos a partir da v21, mas remover Zone.js dum legacy ainda é spike). Vitest pra suite grande. SSR/hydration em rota pública. Cada uma ganha uma ADR escrita (contexto, hipótese, critério de validação, plano de rollback) antes de qualquer código tocar a main.

A terceira lista é a que a maioria dos times pula. Features que parecem modernas, soam modernas, e ainda não cabem em fluxo crítico de produção.

Em junho de 2026, a wait list acabou de provar o valor dela. Signal Forms, as APIs rxResource e resource, e o Angular Aria estavam nela até a v21, e o v22 (junho/2026) graduou os três pra estável, que é exatamente o trigger que a lista existe pra capturar: eles saem de 'esperando' pra 'adotar em código novo'. O que continua na lista agora é a superfície de runtime de IA, tipo o WebMCP, que ainda é experimental e não cabe em billing, compliance ou qualquer fluxo que você não consiga reverter fácil.

A wait list não é 'contra' essas features. É 'ainda não, e aqui está o trigger que tiraria da lista'. Recheque a cada Angular major.

# ADR: spike Vitest no package de orders

Status: proposta
Contexto: suite de testes de orders (~280 specs) roda em 4m20s no Karma; time relata flaky failures em torno de fakeAsync.
Decisão: migrar 1 slice do módulo pra Vitest, medir runtime, estabilidade de CI e custo de migração. Nenhum código de produção tocado.
Escopo: orders/specs apenas. Outros packages intactos.
Fora de escopo: mudar padrões de teste de componente, substituir TestBed.
Riscos: dependências escondidas de Zone.js em helpers compartilhados; diferenças de paralelismo no CI.
Validação: runtime, taxa de flake (janela de 7 dias), revisão da diff de migração pelo time.
Rollback: reverter o package; manter ADR pra próxima tentativa.

A lista 'explicitamente esperando' merece mais cuidado que as outras duas#

Em três bases Angular que ajudei a modernizar entre 2023 e 2026, a lista que esses times nunca tinham era a terceira. Tinham defaults. Tinham spikes. Não tinham registro escrito do que tinham decidido não adotar ainda, nem o porquê.

Um time que documentou o que adota é um time que pensou em modernização. Um time que documentou o que está explicitamente esperando é um time que decidiu.

Sem essa terceira lista, toda PR de modernização vira debate do zero (pq ninguém sabe o que já foi decidido). Com ela, a pergunta de review fica específica: 'a PR propõe Signal Forms pro form de cobrança, mas a wait-list marcou Signal Forms como developer preview. O que mudou no status da API?'

A lista não precisa ser longa. Três a cinco features por vez basta. Cada entrada precisa de (1) o que a gente não tá adotando, (2) por quê (status, raio de impacto, custo de dependência), (3) o trigger que tiraria a feature da lista.

Como comunicar 'a gente não tá adotando isso ainda' sem soar conservador#

Liderança sênior frequentemente escuta 'a gente tá esperando Signal Forms' como 'a gente tá atrasado'. Isso é problema de tradução, não de estratégia.

O reframe: modernização sem wait list é campanha. Modernização com wait list é sequência. Sequência entrega; campanha se arrasta.

Frases específicas que funcionaram nas minhas reviews: 'A gente escalonou a adoção pra acompanhar o track record da API em produção.' 'A gente está adiando X até ver como interage com a arquitetura de forms.' 'A direção do framework é correta; o estado atual (experimental, developer preview) ainda não cabe nos nossos fluxos críticos.'

Essas frases nomeiam a disciplina e dão um lugar pra conversa upstream parar.

Quando revisar cada lista#

Review por calendário falha porque o framework não respeita calendário. Review por trigger funciona.

Quando o Angular team comunica adoção, tende a comunicar com dado de produção. No anúncio do v20, Minko Gechev (líder do Angular team) destacou que o YouTube reduziu input latency em 35% no Living Room usando Angular Signals com Wiz. Um time que mantém a wait-list aprende a ler esse tipo de sinal antes de promover features para 'default'.

Triggers que vale ligar ao seu processo:

O ponto#

Pra um time em produção, o que sobrevive a um Angular major são as decisões que você escreveu, onde elas moram, e como o time encontra essas decisões às 21h de uma sexta quando um release manager pergunta 'a gente tá usando Signal Forms em billing ou não?'.