Salta al contenuto principale

10 - Migrare da Angular 17 ad Angular 21: Guida Pratica

Guida step-by-step per migrare da Angular 17 a 21: ng update, breaking changes per versione, compatibilita librerie, testing e checklist finale.

Cosa ne pensi di questo articolo?

10 - Migrare da Angular 17 ad Angular 21: Guida Pratica
Angular ModernoFoto:Marc MuellerPexels

In Breve

Guida step-by-step per migrare da Angular 17 a 21: ng update, breaking changes per versione, compatibilita librerie, testing e checklist finale.

Migrare da Angular 17 ad Angular 21: Guida Pratica

Migrare un'applicazione Angular attraverso quattro major version può sembrare un'impresa titanica, ma il team Angular ha investito enormemente nella backward compatibility e negli strumenti di migrazione automatica. Ogni versione dal 17 al 21 ha introdotto miglioramenti significativi: dal control flow moderno ai Signals stabili, dalla zoneless change detection fino al supporto TypeScript 5.9.

In questo decimo e ultimo articolo della serie Angular Moderno affronteremo la migrazione passo dopo passo, coprendo ogni passaggio da Angular 17 fino alla versione 21. Non si tratta solo di aggiornare le dipendenze: ogni versione porta con se nuove API, deprecazioni e best practice che è fondamentale comprendere per sfruttare al massimo il framework.

Cosa Imparerai in Questo Articolo

  • La roadmap delle novità introdotte in Angular 18, 19, 20 e 21
  • Come preparare il progetto prima di avviare la migrazione
  • Procedura step-by-step per ogni salto di versione (17→18→19→20→21)
  • Comandi ng update e gestione delle breaking changes
  • Aggiornamento delle dipendenze di terze parti (Angular Material, NgRx, etc.)
  • Come eseguire i test dopo ogni fase della migrazione
  • Checklist completa per validare la migrazione

Panoramica della Serie Angular Moderno

# Articolo Focus
1Angular SignalsReattività fine-grained
2Zoneless Change DetectionEliminare Zone.js
3Nuovi Template @if, @for, @deferControl flow moderno
4Standalone ComponentsArchitettura senza NgModule
5Signal FormsForm reattivi con Signals
6SSR e Incremental HydrationServer-Side Rendering
7Core Web Vitals in AngularPerformance e metriche
8Angular PWAProgressive Web App
9Dependency Injection AvanzataDI tree-shakable
10Sei qui → Migrare da Angular 17 a 21Guida alla migrazione

1. Panoramica delle Versioni: da Angular 17 a 21

Prima di procedere con la migrazione, è essenziale comprendere le novità chiave introdotte in ogni versione. Angular segue un rilascio semestrale: ogni major version porta nuove funzionalità, stabilizzazione di API sperimentali e occasionali breaking changes.

Timeline delle Release e Novità Principali

Versione Release TypeScript Novità Chiave
Angular 17 Nov 2023 5.2 - 5.3 Control flow (@if, @for, @switch), @defer, Signals developer preview, nuovo branding
Angular 18 Mag 2024 5.4 - 5.5 Zoneless developer preview, signal inputs/outputs stabili, deferrable views stabili
Angular 19 Nov 2024 5.6 - 5.7 Standalone default, incremental hydration, linkedSignal, resource API
Angular 20 Mag 2025 5.8 Zoneless stabile, signal forms preview, effect() migliorato, authoring format
Angular 21 Nov 2025 5.9 Zoneless default per nuovi progetti, TypeScript 5.9, performance runtime

Come si può notare, il filo conduttore delle ultime quattro versioni è chiaro: Signals come primitiva reattiva centrale, eliminazione di Zone.js e semplificazione dell'architettura tramite standalone components. Ogni migrazione costruisce sulle fondamenta della precedente.

2. Preparazione alla Migrazione

Una migrazione di successo inizia molto prima del primo ng update. La fase di preparazione è cruciale per evitare problemi imprevisti e ridurre i tempi di fermo. Ecco i passaggi fondamentali.

Verifica della Compatibilità

Prima di tutto, controlla la versione corrente del progetto e le dipendenze installate. Ogni versione di Angular richiede una versione minima di Node.js e TypeScript.

Requisiti di Sistema per Versione

Angular Node.js Minimo Node.js Raccomandato TypeScript RxJS
17.x 18.13 20.x 5.2 - 5.3 7.x
18.x 18.19 20.x / 22.x 5.4 - 5.5 7.x
19.x 18.19 22.x 5.6 - 5.7 7.x
20.x 20.x 22.x 5.8 7.x
21.x 20.x 22.x 5.9 7.x

Checklist Pre-Migrazione

Verifiche preliminari

# 1. Verifica la versione corrente di Angular
ng version

# 2. Controlla la versione di Node.js
node --version

# 3. Assicurati che il repository sia pulito
git status

# 4. Crea un branch dedicato alla migrazione
git checkout -b feat/angular-21-migration

# 5. Esegui i test correnti per avere una baseline
npm test -- --watch=false

# 6. Build di produzione per verifica baseline
npm run build

# 7. Verifica le dipendenze obsolete
npm outdated

# 8. Controlla vulnerabilità
npm audit
    

Regola d'Oro della Migrazione Angular

Mai saltare le versioni. Angular supporta la migrazione solo di una major version alla volta. Se sei su Angular 17, devi passare per 18, poi 19, poi 20 e infine 21. Ogni passaggio include schematiche automatiche che aggiornano il codice, e queste sono progettate per funzionare solo tra versioni consecutive.

3. Angular 17 → 18: Control Flow e Signal Inputs

Il primo salto è spesso il più significativo in termini di refactoring del codice. Angular 18 ha stabilizzato il control flow moderno (@if, @for, @switch) introdotto come developer preview in Angular 17, e ha portato i signal inputs e gli signal outputs alla stabilità.

Comandi di Aggiornamento

ng update per Angular 17 → 18

# Aggiorna Angular CLI e Core
ng update @angular/core@18 @angular/cli@18

# Se usi Angular Material
ng update @angular/material@18

# Se usi Angular CDK
ng update @angular/cdk@18

# Risolvi eventuali conflitti peer dependencies
npm install --legacy-peer-deps
    

Migrazione Automatica del Control Flow

Angular 18 include una schematica che converte automaticamente le direttive strutturali (*ngIf, *ngFor, *ngSwitch) nella nuova sintassi a blocchi.

Eseguire la migrazione automatica del control flow

# Migrazione automatica del control flow
ng generate @angular/core:control-flow

# Oppure, per un singolo progetto in un workspace
ng generate @angular/core:control-flow --project=my-app

# Dopo la migrazione, verifica i cambiamenti
git diff
    

Prima e Dopo: Control Flow

Prima (Angular 17 - direttive strutturali)

<!-- *ngIf con else -->
<div *ngIf="user; else noUser">
  Benvenuto, {{ user.name }}
</div>
<ng-template #noUser>
  <p>Effettua il login</p>
</ng-template>

<!-- *ngFor con trackBy -->
<ul>
  <li *ngFor="let item of items; trackBy: trackById">
    {{ item.name }}
  </li>
</ul>

<!-- *ngSwitch -->
<div [ngSwitch]="status">
  <p *ngSwitchCase="'active'">Attivo</p>
  <p *ngSwitchCase="'inactive'">Inattivo</p>
  <p *ngSwitchDefault>Sconosciuto</p>
</div>
    
Dopo (Angular 18 - control flow moderno)

<!-- @if con @else -->
@if (user) {
  <div>Benvenuto, {{ user.name }}</div>
} @else {
  <p>Effettua il login</p>
}

<!-- @for con track -->
<ul>
  @for (item of items; track item.id) {
    <li>{{ item.name }}</li>
  } @empty {
    <li>Nessun elemento</li>
  }
</ul>

<!-- @switch -->
@switch (status) {
  @case ('active') { <p>Attivo</p> }
  @case ('inactive') { <p>Inattivo</p> }
  @default { <p>Sconosciuto</p> }
}
    

Signal Inputs e Outputs

Migrazione da @Input/@Output a signal inputs/outputs

// PRIMA (Angular 17) - decoratori classici
@Component({ selector: 'app-user-card' })
export class UserCardComponent {
  @Input() name: string = '';
  @Input() age: number = 0;
  @Output() selected = new EventEmitter<string>();

  onClick(): void {
    this.selected.emit(this.name);
  }
}

// DOPO (Angular 18) - signal inputs/outputs
import { input, output } from '@angular/core';

@Component({ selector: 'app-user-card' })
export class UserCardComponent {
  name = input<string>('');
  age = input<number>(0);
  selected = output<string>();

  onClick(): void {
    this.selected.emit(this.name());
  }
}
    

Novità Chiave di Angular 18

  • Control flow stabile: @if, @for, @switch e @defer completamente stabili
  • Signal inputs/outputs: API input() e output() stabili
  • Zoneless developer preview: Primo supporto per applicazioni senza Zone.js
  • Fallback content per ng-content: Contenuto di default per la proiezione
  • Route redirects con funzioni: Redirect dinamici basati su logica
  • Firebase App Hosting: Nuovo servizio di hosting ottimizzato per Angular

4. Angular 18 → 19: Standalone Default e Hydration

Angular 19 rappresenta un cambiamento architetturale importante: i standalone components diventano il default. Il flag standalone: true non è più necessario perchè tutti i componenti sono standalone per default. Inoltre, l'incremental hydration raggiunge la stabilità, e nuove primitive reattive come linkedSignal e la resource API fanno la loro comparsa.

Comandi di Aggiornamento

ng update per Angular 18 → 19

# Aggiorna Angular CLI e Core
ng update @angular/core@19 @angular/cli@19

# Se usi Angular Material
ng update @angular/material@19

# Verifica e correggi i warning di deprecazione
ng build 2>&1 | grep -i "deprecated"
    

Standalone per Default

La schematica di Angular 19 rimuove automaticamente standalone: true da tutti i componenti, poichè diventa il comportamento di default. Se un componente NON è standalone, dovrà ora dichiarare esplicitamente standalone: false.

Prima e dopo: standalone default

// PRIMA (Angular 18) - standalone esplicito
@Component({
  standalone: true,      // Richiesto esplicitamente
  selector: 'app-header',
  imports: [RouterLink, NgOptimizedImage],
  templateUrl: './header.component.html',
})
export class HeaderComponent {}

// DOPO (Angular 19) - standalone per default
@Component({
  // standalone: true è implicito, rimosso dalla schematica
  selector: 'app-header',
  imports: [RouterLink, NgOptimizedImage],
  templateUrl: './header.component.html',
})
export class HeaderComponent {}
    

linkedSignal e resource API

Nuove API reattive di Angular 19

import { signal, linkedSignal, resource } from '@angular/core';

@Component({ selector: 'app-product-list' })
export class ProductListComponent {
  // linkedSignal: signal derivato con possibilità di override
  selectedCategory = signal('electronics');
  currentPage = linkedSignal(() => {
    // Resetta a pagina 1 quando cambia la categoria
    this.selectedCategory();
    return 1;
  });

  // resource API: caricamento dati asincrono reattivo
  products = resource({
    request: () => ({
      category: this.selectedCategory(),
      page: this.currentPage()
    }),
    loader: async ({ request }) => {
      const response = await fetch(
        `/api/products?cat=${request.category}&page=${request.page}`
      );
      return response.json();
    }
  });

  changePage(page: number): void {
    this.currentPage.set(page);
  }
}
    

Novità Chiave di Angular 19

  • Standalone default: Tutti i componenti sono standalone per default
  • Incremental hydration stabile: Hydration progressiva basata su trigger (viewport, hover, timer)
  • linkedSignal: Signal derivato con valore sovrascrivibile (developer preview)
  • resource API: Caricamento asincrono integrato con Signals
  • Strict standalone enforcement: Errore di compilazione per import mancanti
  • Miglioramenti SSR: Event replay per interazioni durante l'hydration

5. Angular 19 → 20: Zoneless Stabile e Signal Forms

Angular 20 segna un traguardo storico: la zoneless change detection diventa stabile. Dopo quasi due anni di developer preview, le applicazioni Angular possono ufficialmente eliminare Zone.js con piena garanzia di stabilità. Inoltre, le signal forms fanno la loro comparsa come developer preview, proponendo un nuovo modo di gestire i form basato interamente su Signals.

Comandi di Aggiornamento

ng update per Angular 19 → 20

# Aggiorna Angular CLI e Core
ng update @angular/core@20 @angular/cli@20

# Se usi Angular Material
ng update @angular/material@20

# Dopo l'aggiornamento, avvia il server di sviluppo
ng serve
    

Adottare la Zoneless Change Detection

Con Angular 20, puoi rimuovere Zone.js in modo sicuro. La schematica non lo fa automaticamente per evitare rotture, ma è il momento giusto per adottare il zoneless se non l'hai ancora fatto.

Abilitare la zoneless change detection

// app.config.ts - Abilitare zoneless
import { ApplicationConfig, provideZonelessChangeDetection } from '@angular/core';
import { provideRouter } from '@angular/router';
import { provideClientHydration } from '@angular/platform-browser';
import { routes } from './app.routes';

export const appConfig: ApplicationConfig = {
  providers: [
    // Sostituisce provideZoneChangeDetection()
    provideZonelessChangeDetection(),
    provideRouter(routes),
    provideClientHydration(),
  ]
};
    
Rimuovere Zone.js dal progetto

# 1. Rimuovi zone.js dalle dipendenze
npm uninstall zone.js

# 2. Rimuovi il polyfill da angular.json
# Cerca e rimuovi "zone.js" dall'array "polyfills"

# 3. Verifica che non ci siano import diretti
grep -r "zone.js" src/
    

Attenzione: Codice Incompatibile con Zoneless

Alcuni pattern comuni smettono di funzionare senza Zone.js perchè si affidavano alla monkey-patching delle API asincrone. Cerca e correggi questi pattern nel tuo codice:

  • Modifiche dirette a proprietà del componente dopo setTimeout o setInterval: usa signal() al loro posto
  • Uso di Promise.then() per aggiornare lo stato della UI: converti in resource() o usa signal.set()
  • Librerie di terze parti che modificano lo stato al di fuori di Angular: usa inject(ChangeDetectorRef) come workaround temporaneo
  • Test con fakeAsync/tick: sostituisci con await fixture.whenStable()

Novità Chiave di Angular 20

  • Zoneless change detection stabile: provideZonelessChangeDetection() completamente stabile
  • Signal forms (developer preview): Nuove API per form basate su Signals
  • effect() migliorato: Esecuzione sincrona opzionale, migliore integrazione con il lifecycle
  • linkedSignal stabile: Signal derivato con override ora completamente stabile
  • Authoring format sperimentale: Nuovo formato per definire componenti (.ng files)
  • Rimozione API deprecate: Pulizia di API segnate come deprecate da Angular 16-17

6. Angular 20 → 21: TypeScript 5.9 e Zoneless di Default

Angular 21 è la versione che consolida tutto il lavoro delle versioni precedenti. I nuovi progetti generati con ng new sono zoneless per default, TypeScript 5.9 porta miglioramenti al type checking e alla developer experience, e le performance del runtime ricevono ulteriori ottimizzazioni.

Comandi di Aggiornamento

ng update per Angular 20 → 21

# Aggiorna Angular CLI e Core
ng update @angular/core@21 @angular/cli@21

# Se usi Angular Material
ng update @angular/material@21

# Aggiorna TypeScript a 5.9
npm install typescript@5.9 --save-dev

# Verifica la build
ng build
    

TypeScript 5.9: Novità Rilevanti per Angular

Novità TypeScript 5.9 utili in Angular

// 1. Miglioramenti al type narrowing nei template
// TypeScript 5.9 migliora il supporto per il narrowing
// nei blocchi @if dei template Angular

// 2. Import attributes stabili
import data from './config.json' with { type: 'json' };

// 3. Miglioramento delle performance del compiler
// Build più veloci grazie al caching migliorato
// e alla riduzione delle allocazioni di memoria

// 4. Utility types migliorati per i Signals
import { Signal, WritableSignal } from '@angular/core';

// NoInfer<T> previene inferenza indesiderata
function createState<T>(
  initial: T,
  validator: (value: NoInfer<T>) => boolean
): WritableSignal<T> {
  const state = signal(initial);
  // ...logica di validazione
  return state;
}
    

Novità Chiave di Angular 21

  • Zoneless per default: ng new genera progetti senza Zone.js
  • TypeScript 5.9: Supporto completo con miglioramenti al type checking
  • Performance runtime: Ottimizzazioni alla change detection e al rendering
  • Signal forms migliorati: API più mature e complete
  • resource API stabile: Caricamento dati asincrono pienamente stabile
  • Rimozione NgModule-based code: Ulteriore deprecazione delle API basate su moduli

7. ng update Step by Step: La Procedura Completa

Vediamo ora la procedura completa per migrare dalla versione 17 alla 21, inclusa la gestione delle breaking changes e dei conflitti nelle dipendenze. Ogni step deve essere completato e verificato prima di procedere al successivo.

Script completo di migrazione 17 → 21

#!/bin/bash
# Script di migrazione Angular 17 -> 21

echo "=== STEP 1: Angular 17 -> 18 ==="
ng update @angular/core@18 @angular/cli@18
npm install
ng build
npm test -- --watch=false
git add -A && git commit -m "chore: migrate to Angular 18"

echo "=== STEP 2: Angular 18 -> 19 ==="
ng update @angular/core@19 @angular/cli@19
npm install
ng build
npm test -- --watch=false
git add -A && git commit -m "chore: migrate to Angular 19"

echo "=== STEP 3: Angular 19 -> 20 ==="
ng update @angular/core@20 @angular/cli@20
npm install
ng build
npm test -- --watch=false
git add -A && git commit -m "chore: migrate to Angular 20"

echo "=== STEP 4: Angular 20 -> 21 ==="
ng update @angular/core@21 @angular/cli@21
npm install
ng build
npm test -- --watch=false
git add -A && git commit -m "chore: migrate to Angular 21"

echo "=== Migrazione completata! ==="
ng version
    

Gestione delle Breaking Changes

Quando ng update incontra una breaking change, il processo si interrompe con un messaggio di errore. Ecco le strategie per risolvere i problemi più comuni.

Breaking Changes Comuni e Soluzioni

Versione Breaking Change Soluzione
17→18 Rimozione di ViewEngine API residue Sostituisci con Ivy equivalents
18→19 standalone: true diventa default Aggiungi standalone: false ai componenti non-standalone
18→19 Rimozione @angular/http legacy Usa @angular/common/http
19→20 Deprecazione pattern Observable-based per alcuni servizi interni Migra a signal-based equivalents
20→21 TypeScript 5.9 required Aggiorna TypeScript e correggi errori di tipo
20→21 Rimozione API deprecate da v17 Consulta la guida deprecation di Angular

Risolvere i Conflitti nelle Peer Dependencies

Strategie per risolvere conflitti di dipendenze

# Se ng update fallisce per peer dependencies
# Strategia 1: Forza l'aggiornamento
ng update @angular/core@21 @angular/cli@21 --force

# Strategia 2: Aggiorna manualmente le dipendenze in conflitto
npm install @angular/core@21 @angular/cli@21 --legacy-peer-deps
npm install

# Strategia 3: Usa --allow-dirty se hai modifiche non committate
ng update @angular/core@21 --allow-dirty

# Strategia 4: Pulisci e reinstalla da zero
rm -rf node_modules package-lock.json
npm install

# Verifica lo stato delle dipendenze
npm ls @angular/core
    

8. Migrazione delle Dipendenze di Terze Parti

Le dipendenze di terze parti rappresentano spesso il collo di bottiglia principale nella migrazione. Non tutte le librerie supportano immediatamente la nuova versione di Angular, e alcune richiedono aggiornamenti sostanziali. Ecco una guida per le librerie più comuni.

Matrice di Compatibilità delle Librerie Principali

Libreria Angular 18 Angular 19 Angular 20 Angular 21
@angular/material 18.x 19.x 20.x 21.x
@ngrx/store 18.x 19.x 20.x 21.x
@angular/fire 18.x 19.x 18.x+ 19.x+
ng-bootstrap 16.x 17.x 18.x 19.x
ngx-translate 15.x 16.x 16.x+ 16.x+
primeng 17.x 18.x 19.x 19.x+
@ng-icons 27.x 28.x 29.x 30.x+

Strategia per le Dipendenze

Verificare e aggiornare le dipendenze

# 1. Lista tutte le dipendenze Angular-related
npm ls | grep angular

# 2. Controlla le versioni disponibili
npm view @angular/material versions --json | tail -20
npm view @ngrx/store versions --json | tail -20

# 3. Aggiorna le dipendenze principali
ng update @angular/material@21
ng update @ngrx/store@21

# 4. Per librerie senza ng update schematic
npm install ngx-translate@latest
npm install primeng@latest

# 5. Verifica compatibilità dopo l'aggiornamento
ng build
npm test -- --watch=false
    

Dipendenze Non Ancora Aggiornate

Se una libreria di terze parti non supporta ancora la versione target di Angular, hai queste opzioni:

  • Aspetta: Monitora le release della libreria e rinvia la migrazione di quella dipendenza
  • Fork temporaneo: Se necessario, crea un fork con le modifiche minime necessarie
  • --legacy-peer-deps: Ignora il conflitto se la libreria funziona comunque (verificalo con i test)
  • Sostituisci: Valuta alternative compatibili. Ad esempio, da ngx-translate alla i18n nativa di Angular
  • Contribuisci: Apri una PR sulla libreria per aggiungere il supporto alla nuova versione

9. Testing dopo la Migrazione

Dopo ogni step della migrazione, è essenziale verificare che l'applicazione funzioni correttamente. I test automatici sono la tua rete di sicurezza, ma la migrazione stessa può rompere i test esistenti. Ecco come affrontare questa fase.

Eseguire la Test Suite

Procedura di test post-migrazione

# 1. Esegui tutti gli unit test
npm test -- --watch=false --browsers=ChromeHeadless

# 2. Esegui i test e2e (se presenti)
npm run e2e

# 3. Build di produzione (cattura errori AOT)
ng build --configuration=production

# 4. Avvia il server SSR e verifica manualmente
npm run serve:ssr:portfolio

# 5. Controlla che non ci siano warning di deprecazione
ng build 2>&1 | grep -i "warning\|deprecated"

# 6. Verifica le performance con Lighthouse
npx lighthouse http://localhost:4200 --output=json --output-path=./lighthouse-report.json
    

Fix Comuni per i Test Rotti

Aggiornare i test per Angular 21

// PRIMA: TestBed con NgModule-style
beforeEach(async () => {
  await TestBed.configureTestingModule({
    declarations: [MyComponent],   // deprecato con standalone
    imports: [HttpClientTestingModule],
    providers: [MyService]
  }).compileComponents();
});

// DOPO: TestBed con standalone components
beforeEach(async () => {
  await TestBed.configureTestingModule({
    imports: [MyComponent],   // standalone component va in imports
    providers: [
      provideHttpClientTesting(),  // nuovo provider-based testing
      MyService
    ]
  }).compileComponents();
});

// PRIMA: fakeAsync con Zone.js
it('should load data', fakeAsync(() => {
  component.loadData();
  tick(1000);
  expect(component.data).toBeTruthy();
}));

// DOPO: async/await senza Zone.js
it('should load data', async () => {
  component.loadData();
  await fixture.whenStable();
  fixture.detectChanges();
  expect(component.data()).toBeTruthy();  // signal()
});
    

Errori di Test Frequenti dopo la Migrazione

Errore Causa Soluzione
NullInjectorError: No provider for HttpClient HttpClientTestingModule deprecato Usa provideHttpClientTesting()
Component is not a known element Standalone component non importato Aggiungi il component a imports nel TestBed
Cannot read property of signal Signal non invocato come funzione Cambia component.value in component.value()
fakeAsync timer not cleared Zone.js rimosso Converti a async/await
Expression has changed Zoneless change detection Usa fixture.detectChanges() dopo ogni modifica

10. Checklist Finale della Migrazione

Per assicurarti che la migrazione sia completa e che nulla sia stato dimenticato, segui questa checklist dettagliata divisa in tre fasi: pre-migrazione, durante la migrazione e post-migrazione.

Fase 1: Pre-Migrazione

  • Repository pulito: nessuna modifica non committata
  • Branch dedicato creato: feat/angular-21-migration
  • Test suite verde: tutti i test passano sulla versione corrente
  • Build di produzione funzionante: ng build completato senza errori
  • Node.js aggiornato al minimo richiesto (20.x per Angular 20/21)
  • Backup del package.json e package-lock.json
  • Documentazione delle dipendenze di terze parti e relative versioni
  • Review delle breaking changes per ogni versione target su update.angular.io

Fase 2: Durante la Migrazione

  • Migrare una versione alla volta: 17→18→19→20→21
  • Per ogni step: ng update, npm install, ng build, npm test
  • Commit dopo ogni migrazione riuscita
  • Eseguire le schematiche di migrazione automatica (control flow, standalone, etc.)
  • Risolvere ogni warning di deprecazione prima di procedere al prossimo step
  • Aggiornare Angular Material e altre dipendenze Angular alla stessa major version
  • Verificare la compilazione AOT: ng build --configuration=production
  • Controllare la console del browser per errori runtime

Fase 3: Post-Migrazione

  • Tutti i test (unit + e2e) passano
  • Build di produzione completata senza errori ne warning
  • SSR funzionante: verifica con npm run serve:ssr
  • Performance verificata: Lighthouse score ≥ 90 su tutte le categorie
  • Zero warning di deprecazione nel log di build
  • Dipendenze di terze parti tutte compatibili e aggiornate
  • Zoneless change detection adottata (consigliato)
  • Control flow moderno (@if, @for) al posto delle direttive strutturali
  • Signal inputs/outputs al posto dei decoratori @Input/@Output
  • Test aggiornati per le nuove API (provideHttpClientTesting, etc.)
  • package-lock.json committato e pulito
  • Deploy in ambiente di staging per test manuali prima della produzione

Riepilogo e Conclusione della Serie

La migrazione da Angular 17 a 21 non è solo un aggiornamento di versione: è un'evoluzione dell'intera architettura della tua applicazione. Passare dal vecchio modello basato su Zone.js e NgModules al nuovo paradigma Signals-first e standalone-by-default rappresenta un miglioramento sostanziale in termini di performance, manutenibilità e developer experience.

La chiave del successo è la gradualità: migrare una versione alla volta, testare ad ogni passaggio, adottare le nuove API progressivamente. Angular è progettato per rendere questo processo il più indolore possibile grazie alle schematiche automatiche e alla eccellente backward compatibility.

Concetti Chiave di Questo Articolo

  • Migrazione graduale: Sempre una major version alla volta (17→18→19→20→21)
  • ng update: Lo strumento principale che aggiorna dipendenze e applica schematiche automatiche
  • Control flow moderno: @if, @for, @switch sostituiscono *ngIf, *ngFor, *ngSwitch
  • Signal inputs/outputs: input() e output() sostituiscono @Input e @Output
  • Standalone default: Da Angular 19 tutti i componenti sono standalone per default
  • Zoneless stabile: Da Angular 20 puoi eliminare Zone.js in sicurezza
  • TypeScript 5.9: Angular 21 richiede TypeScript 5.9 per le nuove feature
  • Testing: Aggiorna i test da NgModule-style a standalone e da fakeAsync a async/await
  • Dipendenze: Aggiorna Angular Material, NgRx e librerie di terze parti alla stessa major

Riepilogo Completo della Serie Angular Moderno

# Articolo Concetto Principale
1Angular SignalsReattività fine-grained con signal(), computed(), effect()
2Zoneless Change DetectionEliminare Zone.js per performance superiori
3Template @if, @for, @deferControl flow moderno e lazy loading dichiarativo
4Standalone ComponentsArchitettura senza NgModule, tree-shakable
5Signal FormsForm reattivi basati su Signals
6SSR e Incremental HydrationServer-Side Rendering con hydration progressiva
7Core Web VitalsOttimizzazione LCP, INP, CLS per il ranking Google
8Angular PWAProgressive Web App con Service Worker
9Dependency Injection AvanzataDI tree-shakable, injection token, multi-provider
10Migrare da Angular 17 a 21Guida completa alla migrazione step-by-step

Con questo articolo si conclude la serie Angular Moderno. Abbiamo coperto tutti gli aspetti fondamentali del framework, dalle primitive reattive (Signals) alla gestione dello stato (Signal Forms), dalle strategie di rendering (SSR, hydration) all'ottimizzazione delle performance (Core Web Vitals, PWA), dall'architettura (standalone, DI avanzata) alla migrazione pratica. Speriamo che questa serie ti sia stata utile per padroneggiare Angular nella sua incarnazione più moderna e performante.

Domande frequenti

Quali sono le principali novità introdotte nelle ultime quattro versioni di Angular?

Le principali novità introdotte nelle ultime quattro versioni di Angular sono Signals come primitiva reattiva centrale, eliminazione di Zone.js e semplificazione dell'architettura tramite standalone components.

Qual è la fase più importante per evitare problemi imprevisti durante la migrazione?

La fase di preparazione è cruciale per evitare problemi imprevisti e ridurre i tempi di fermo. È fondamentale verificare la compatibilità con la versione corrente del progetto e le dipendenze installate.

Come si possono risolvere i conflitti nelle peer dependencies durante la migrazione?

I conflitti nelle peer dependencies possono essere risolti utilizzando strategie come l'aggiornamento delle dipendenze, la rimozione di dipendenze obsolete o la sostituzione con alternative compatibili.

Qual è il ruolo dei test automatici nella migrazione da Angular 17 a 21?

I test automatici sono essenziali per verificare che l'applicazione funzioni correttamente dopo ogni passaggio della migrazione. La migrazione stessa può rompere i test esistenti, quindi è importante eseguire la test suite e risolvere eventuali problemi con i fix comuni per i test rotti.

Fonti e approfondimenti

Prova Questi Strumenti

Strumenti gratuiti correlati a questo argomento.

Commenti

Caricamento commenti...

Accedi per commentare

Discuti questo articolo nella community

Unisciti al gruppo Telegram per discutere con altri sviluppatori, fare domande e condividere le tue esperienze.

Ti è piaciuto questo articolo?

Esplora altri contenuti sul blog o scopri i miei progetti