Modern Angular
Um plano de 30 dias para modernizar apps Angular maduros
Se modernizar Angular parece vago demais, coloque no calendário: auditoria primeiro, mudanças pequenas depois, ideias arriscadas em branch e decisões por escrito. Com o Angular soltando um major a cada seis meses e cinco majors entre v16 e v21, uma sequência escrita é o que impede a modernização de virar campanha.
Dias 1-3: auditoria antes de opinião
Rode ng version, registre Angular, CLI, TypeScript, Node, RxJS, Material/CDK, builders, test runner e dependências críticas de terceiros. Rode build de produção e testes. Liste warnings antes de corrigir. O update guide oficial é a segunda aba certa pra deixar aberta, já que customiza por versão de origem, versão alvo, complexidade e dependências tipo ngUpgrade ou Material.
Procure dependências de Zone.js, subscriptions manuais, timers, NgModules, SharedModules grandes, reactive forms, fronteiras de NgRx e bibliotecas que mexem muito no DOM. A saída é um documento curto de baseline. Se o primeiro PR já muda comportamento, a auditoria chegou tarde.
# Baseline de modernização Angular
Angular / CLI:
Node / TypeScript / RxJS:
Comando de build:
Comando de teste:
Bloqueadores conhecidos:
Primeiro piloto de baixo risco:
Explicitamente fora de escopo:Dias 4-13: alinhamento de baixo risco
Comece alinhando o código novo aos padrões atuais do Angular. Use standalone em componentes novos isolados, control flow moderno em templates já alterados e Signals para estado local onde reduzem boilerplate.
A documentação oficial de migração standalone é explícita sobre a rede de segurança: 'Existing applications can optionally and incrementally adopt the new standalone style without any breaking changes.' Essa postura é o que torna o trabalho das semanas 1-2 viável. Schematics como ng generate @angular/core:standalone e ng generate @angular/core:control-flow cobrem a parte mecânica; o review do time fica focado no padrão a repetir.
Não converta a aplicação inteira só para defender uma tese. O objetivo é um padrão repetível que o time consiga revisar. Se o segundo PR é difícil de explicar, o padrão ainda não está pronto.
Dias 14-23: spikes controlados
| Spike | Pergunta | Evidência |
|---|---|---|
| Zoneless | Quais fluxos quebram quando change detection fica explícita? | Smoke tests para timers, forms, subscriptions, overlays e charts. |
| Vitest | Uma fatia da suíte roda mais rápido sem quebrar tooling? | CI com specs migradas e diferenças conhecidas de mocks/fake timers. |
| SSR/hydration | Rotas públicas precisam de renderização no servidor? | Baseline de web vitals, auditoria de DOM e teste de hydration. |
| Signal Forms | Existe uma tela de baixo risco onde o experimento ensina o time? | Branch isolada com docs atuais, sem dependência crítica de produção. |
Entregáveis por semana
O plano só é útil se toda semana deixa algo que o time consegue revisar. Eu não mediria pelo número de APIs tocadas; mediria por quanto o próximo reviewer consegue decidir com menos risco.
| Semana | Entregável | Pergunta de review |
|---|---|---|
| Semana 1 | Baseline técnico | Sabemos versões, bloqueadores, padrões de risco e comandos? |
| Semana 2 | PR piloto | Um padrão de baixo risco melhorou ownership sem churn amplo? |
| Semana 3 | Relatórios de spike | Falhas, timings e rollback vieram do app real? |
| Semana 4 | ADRs e backlog | O time sabe o que vira default, fica adiado ou sai de escopo? |
Dias 24-30: decidir e documentar
A última semana não é para adicionar mais experimentos. É para escrever decisões: o que vira default em código novo, o que será migrado quando tocar, o que precisa de mais evidência e o que explicitamente não vai acontecer agora.
A saída deve ser simples e explícita: control flow aprovado para templates já alterados, zoneless adiado depois de falhas em overlay, Signal Forms bloqueado em forms críticos enquanto a API for experimental, Vitest liberado só em pacote piloto até o CI trazer dados melhores.
Uma ADR curta basta. Inclua contexto, decisão, escopo, fora de escopo, riscos e comandos de validação. Isso importa porque modernização fica cara quando cada reviewer precisa redescobrir a mesma decisão.
# ADR: usar Signals para estado local em componentes novos
Status: proposta
Contexto: app existente, padrões mistos para estado local, sem uso de Signals
Decisão: adotar Signals locais em componentes novos e tocados; manter RxJS para streams assíncronos
Escopo: código novo e features de baixo risco que já vão mudar
Fora de escopo: substituir NgRx, services ou streams assíncronos
Riscos: mau uso de effect, padrões mistos, reescrita acidental
Validação: testes, smoke flow, checklist de code reviewArtefato para reaproveitar
Sequência de 30 dias
- Dias 1-3: auditar versões, testes, CI, dependências e padrões de risco.
- Dias 4-13: entregar um PR piloto de baixo risco que reviewers conseguem repetir.
- Dias 14-23: rodar spikes isolados para zoneless, Vitest, SSR e APIs experimentais.
- Dias 24-30: escrever ADRs, itens de backlog e não-objetivos explícitos.
Fontes consultadas
- https://angular.dev/reference/releases
- https://angular.dev/update-guide
- https://angular.dev/reference/migrations
- https://angular.dev/reference/migrations/standalone
- https://angular.dev/reference/migrations/control-flow
- https://angular.dev/reference/migrations/inject-function
- https://angular.dev/reference/migrations/signal-inputs
- https://angular.dev/guide/components
- https://angular.dev/guide/signals
- https://angular.dev/guide/templates/control-flow
- https://angular.dev/guide/zoneless
- https://angular.dev/guide/testing/migrating-to-vitest
- https://angular.dev/guide/forms/signals/overview
Modern Angular Playbook
Este artigo é um play.
O Playbook do Angular Moderno reúne o diagnóstico, a matriz de adoção, onze jogadas e o plano de 30 dias. Grátis, em inglês e português.
Você recebe os dois PDFs por email, pela lista do Dojo IA.
André Ramosdisponível para vagas remotas, UTC−3Entre em contato →