Angular 22, rilasciato il 3 giugno 2026, è la versione stabile più recente del framework al momento della stesura di questo articolo. Rispetto ad Angular 21 (novembre 2025, che aveva reso zoneless il default e introdotto Signal Forms come API sperimentale), questa release consolida in stabile production-ready tutto ciò che era ancora in developer preview: Signal Forms, Resource API e Angular Aria diventano ufficialmente utilizzabili in produzione, i default di alcune API cambiano verso pattern più moderni, e arriva un primo strato di tooling AI integrato nella CLI.
Come sempre con una release recente, verifica la versione esatta installata e le note di rilascio
ufficiali prima di pianificare un upgrade in produzione: ng version e npm view
@angular/core versions restituiscono lo stato reale del tuo progetto e del registry npm,
più affidabili di qualunque riepilogo statico.
Panoramica Rapida
- Signal Forms stabili: il sistema di form basato su Signal, sperimentale in v21, è ora production-ready.
- Resource API stabile:
resource(),rxResource()ehttpResource()passano da sperimentale a stabile. - Angular Aria stabile: il pacchetto
@angular/ariaper pattern di accessibilità passa da developer preview a disponibilità generale. - OnPush come default: i nuovi componenti usano
OnPushinvece diEagerper la change detection. - Fetch API come default per HttpClient: sostituisce XMLHttpRequest, con
withFetch()deprecato perché ormai superfluo. - Tooling AI nella CLI: Angular Skills e supporto WebMCP sperimentale per agenti di coding.
- TypeScript 6 richiesto: requisito minimo alzato, Node 20 non più supportato (minimo Node 22).
Dettaglio Feature
Signal Forms: da Sperimentale a Stabile
Signal Forms combina la tipizzazione forte dei reactive form tradizionali con la reattività granulare
dei Signal, eliminando gran parte del boilerplate di FormGroup/FormControl.
In questa versione arrivano validator minDate()/maxDate(), debounce nativo
sugli eventi di blur, e un metodo getError() per recuperare errori mirati senza
attraversare l'intero albero del form.
// Signal Forms — validazione con debounce sul blur, stabile da v22
const form = signalForm({
email: field('', { validators: [required(), email()] }),
});
debounce(form.email, 'blur', 300);
Resource API: Data Fetching Reattivo
// httpResource() — fetching dichiarativo, nessun switchMap manuale
userResource = httpResource(() => `/api/users/${this.userId()}`);
// userResource.value(), userResource.isLoading(), userResource.error() sono Signal reattivi
Novità di questa versione: un metodo chain() per comporre resource dipendenti l'una
dall'altra senza annidare manualmente effect(), e supporto alla cache lato SSR tramite
un'opzione id, utile per evitare doppio fetching tra rendering server e hydration client.
OnPush di Default e Fetch API di Default
// Da Angular 22, un componente senza changeDetection esplicito è OnPush per default
@Component({ selector: 'app-widget', template: `...` })
export class WidgetComponent {} // equivalente a changeDetection: ChangeDetectionStrategy.OnPush
HttpClient usa Fetch API invece di XMLHttpRequest senza bisogno di
withFetch() esplicito (ora deprecato in vista della rimozione); attenzione se il tuo
codice dipende da reportProgress per l'upload, perché il reporting di progresso in
upload non è supportato dall'implementazione Fetch e va gestito con i nuovi
reportUploadProgress/reportDownloadProgress.
@Service Decorator e injectAsync()
// @Service — scorciatoia per @Injectable({ providedIn: 'root' }), richiede inject() non constructor DI
@Service()
export class NotificationService {
private readonly http = inject(HttpClient);
}
// injectAsync() — lazy loading di un servizio via dynamic import, con prefetch opzionale
const analytics = await injectAsync(() => import('./analytics.service'), { prefetch: 'onIdle' });
Angular Aria: Accessibilità come Infrastruttura
@angular/aria, ora in disponibilità generale, fornisce direttive che gestiscono
automaticamente attributi ARIA, navigazione da tastiera e focus management per pattern composti
(combobox, tab, tree) — lo sviluppatore si concentra sul design visivo e la logica di business, non
sulla reimplementazione manuale dell'ARIA Authoring Practices Guide per ogni componente.
Breaking Changes e Deprecazioni
- TypeScript 6 obbligatorio: 5.9 e versioni precedenti non sono più supportate — aggiorna TypeScript prima di eseguire
ng update. - Node 20 rimosso: il minimo supportato è Node 22 (Node 26 supportato).
touchednei Signal Forms cambiato: da model a coppia input/output (touchedinput,touch()output) — impatto diretto sul codice che leggeva/scrivevatouchedcome model.markAsTouched()ora marca i discendenti di default: usa{ skipDescendants: true }per preservare il comportamento precedente se il tuo codice lo assumeva.- Router:
canMatchrichiede un terzo parametro obbligatorio (currentSnapshot) — le guardie esistenti vanno aggiornate nella firma. paramsInheritanceStrategyora'always'di default (era'emptyOnly'): verifica se il tuo routing dipendeva dal vecchio comportamento implicito.- Optional chaining nei template cambia semantica:
project?.authorora restituisceundefinedinvece dinullsu valori nulli, allineandosi a TypeScript. withIncrementalHydration()deprecato perché ora è il default SSR; usawithNoIncrementalHydration()se serve esplicitamente il vecchio comportamento.
Tooling e Build
# Migrazione automatica dei test da Karma a Vitest
ng generate migrate-karma-to-vitest
# Build con ottimizzazione dei chunk abilitata di default (disattivabile via env var)
NG_BUILD_OPTIMIZE_CHUNKS=false ng build --configuration production
Rollup resta l'ottimizzatore di default, ma Rolldown è disponibile come opzione tramite
NG_BUILD_CHUNKS_ROLLDOWN per chi vuole sperimentare tempi di build ulteriormente ridotti.
La variabile d'ambiente PORT ora ha precedenza sul flag --port per il dev
server, utile per configurazioni CI/CD containerizzate.
Performance e Bundle
OnPush come default riduce il numero di cicli di change detection non necessari già a
partire da nuovi progetti scaffoldati, senza bisogno di configurazione manuale. L'ottimizzazione dei
chunk abilitata di default nella build di produzione riduce ulteriormente il bundle iniziale rispetto
alle versioni precedenti. Misura sempre prima/dopo con gli strumenti standard:
ng build --configuration production --stats-json
npx webpack-bundle-analyzer dist/*/stats.json
npx lighthouse http://localhost:4200 --view
State Management e Reattività
Con Signal Forms e Resource API entrambi stabili, il pattern raccomandato per nuovo codice è ormai
Signal-first: stato locale con signal()/computed(), data fetching con
resource()/httpResource(), form con Signal Forms. RxJS resta pienamente
supportato e necessario per stream complessi (WebSocket, eventi multipli combinati), ma non è più il
default implicito per ogni nuovo componente. Novità sperimentale di questa versione: debounced(),
una funzione che crea una versione debounced di un Signal restituendo un oggetto Resource.
// debounced() — sperimentale, debounce di un Signal senza RxJS
const query = signal('');
const debouncedQuery = debounced(query, { delay: 300 });
Server-Side Rendering ed Edge
L'hydration incrementale è ora il comportamento SSR di default (non più opt-in tramite
withIncrementalHydration(), che infatti è deprecato proprio perché superfluo).
provideServerRendering() accetta ora un oggetto di opzioni, incluso
maxResponseBodySize per limitare la dimensione della risposta renderizzata lato server —
utile su piattaforme edge con limiti stringenti di payload per singola function.
// provideServerRendering con opzioni — utile su piattaforme edge con limiti di response size
provideServerRendering({ maxResponseBodySize: 5_000_000 });
Compatibilità e Dipendenze
| Angular | TypeScript | Node | Note |
|---|---|---|---|
| 21 | 5.6+ | 20 / 22 | Zoneless default, Signal Forms sperimentali |
| 22 | 6.0 minimo | 22 / 26 (20 rimosso) | Signal Forms/Resource API/Aria stabili |
Per Angular Material, NgRx e altre librerie dell'ecosistema, verifica sempre la compatibilità
dichiarata nel peerDependencies del pacchetto specifico prima dell'upgrade:
npm view @angular/material peerDependencies. Librerie che dipendono pesantemente da
FormControl/FormGroup tradizionali restano compatibili — Signal Forms
coesiste con le API reattive/template-driven legacy, non le sostituisce forzatamente.
Migrazione e Piano Operativo
# Verifica prima di aggiornare
ng version
npm outdated
# Aggiornamento a v22 con dry-run preventivo
ng update @angular/core@22 @angular/cli@22 --dry-run
ng update @angular/core@22 @angular/cli@22
Checklist minima pre-upgrade: TypeScript già a 6.x, Node già a 22+, branch dedicato, build e test verdi come baseline. Dopo l'update, esegui l'intera suite di test e una build di produzione completa prima di procedere a qualsiasi adozione opzionale (Signal Forms, Aria) sui componenti esistenti — l' upgrade della versione e l'adozione delle nuove API sono due attività distinte, non vanno unite nello stesso commit. Per il rollback, il tag Git pre-upgrade resta il meccanismo più rapido e affidabile.
Testing e QA
// TestBed.getLastFixture() — nuova utility per recuperare l'ultima fixture creata
it('renderizza correttamente', () => {
TestBed.createComponent(WidgetComponent);
const fixture = TestBed.getLastFixture();
expect(fixture.nativeElement.textContent).toBeTruthy();
});
Vitest ora ha supporto nativo per Zone.js tramite zone.js/plugins/vitest-patch, e la
migrazione automatica migrate-karma-to-vitest copre la maggior parte dei progetti Karma
esistenti; per chi già migrato a Jasmine/Vitest, il flag --fake-async sulla migrazione
refactor-jasmine-vitest copre pattern di test asincroni basati su timer.
Sicurezza e Best Practice
Nessun cambio di default relativo a cookie o CSP in questa release specifica, ma il passaggio a Fetch
API per HttpClient merita una verifica: se la tua applicazione dipende da comportamenti
specifici di XMLHttpRequest (es. header custom su richieste cross-origin), testa esplicitamente i
flussi di autenticazione dopo l'upgrade. Le best practice restanti (HttpOnly/SameSite sui cookie di
sessione, CSP restrittiva) non cambiano e vanno mantenute indipendentemente dalla versione Angular.
Casi d'Uso
Caso 1: Dashboard Enterprise con Form Complessi
Una dashboard enterprise con oltre 40 form distribuiti su vari moduli ha adottato Signal Forms sui form di nuova feature dopo l'upgrade a v22, mantenendo i form legacy su reactive form tradizionali grazie alla piena coesistenza delle due API. Risultato: boilerplate ridotto di circa il 30% sui nuovi form, validazione con debounce nativo che ha eliminato codice custom di debounce scritto a mano su RxJS in precedenza.
Caso 2: App con Requisiti di Accessibilità Stringenti
Un'applicazione pubblica soggetta a requisiti WCAG AA ha sostituito l'implementazione custom di
combobox e tab (con gestione ARIA scritta manualmente) con @angular/aria dopo la
stabilizzazione in v22. Risultato: audit di accessibilità automatico passato senza intervento manuale
aggiuntivo sui pattern migrati, riduzione del codice di gestione focus/tastiera specifico per
componente di circa 200 righe totali.
FAQ
Serve migrare subito tutti i form a Signal Forms?
No, Signal Forms coesiste con reactive/template-driven form legacy; la migrazione può essere graduale e opportunistica.
OnPush come default rompe componenti esistenti?
No, il default si applica solo ai nuovi componenti senza changeDetection esplicito; i componenti esistenti mantengono la strategia già dichiarata.
Devo aggiornare Node prima di aggiornare Angular?
Sì, Node 20 non è più supportato in v22: verifica e aggiorna Node a 22+ prima di eseguire ng update.
Fetch API di default rompe le chiamate HTTP esistenti?
Nella maggior parte dei casi no, ma verifica il reporting di progresso upload, che richiede le nuove opzioni dedicate invece del vecchio reportProgress.
Angular Aria sostituisce Angular Material?
No, sono complementari: Aria fornisce pattern di accessibilità comportamentale, Material fornisce componenti visivi già stilizzati.
Cosa succede se non aggiorno TypeScript a 6?
ng update a v22 fallirà o segnalerà l'incompatibilità: TypeScript 6 è un requisito obbligatorio, non opzionale.
Vitest sostituisce obbligatoriamente Karma?
Non immediatamente obbligatorio, ma Karma è in fase di deprecazione nell'ecosistema Angular; la migrazione automatica rende il passaggio a Vitest a basso rischio.
Il tooling AI/MCP è necessario per usare Angular 22?
No, è opzionale e pensato per chi usa agenti di coding assistiti da AI; non impatta il funzionamento standard dell'applicazione.
Come Verificare
- Verifica versione e dipendenze:
ng versionenpm outdated. - Build di produzione completa:
ng build --configuration production. - Esegui l'intera suite di test:
ng test(ovitest runse già migrato). - Smoke test manuale sui flussi critici (auth, form principali) dopo l'upgrade.
- Test E2E completi:
npx cypress runo equivalente. - Verifica bundle size e performance: bundle analyzer più
npx lighthouse http://localhost:4200, confrontati con la baseline pre-upgrade.
Conclusione
Angular 22 non introduce un cambio di paradigma quanto un consolidamento: le API Signal-based nate nelle versioni precedenti (Signal Forms, Resource API) diventano finalmente stabili e pronte per la produzione, i default si spostano verso pattern più performanti (OnPush, Fetch API), e arriva un primo strato di tooling pensato per lo sviluppo assistito da AI. Per la maggior parte dei progetti, l'upgrade da v21 è a basso rischio se TypeScript e Node sono già aggiornati; l'adozione delle nuove API resta comunque opzionale e può procedere gradualmente dopo l'upgrade della versione.
Vuoi una checklist di migrazione dettagliata per il tuo progetto o una valutazione dell'effort di upgrade? Richiedi un audit tecnico: in poche ore di analisi è possibile stimare rischi, breaking change rilevanti per la tua codebase e priorità di adozione delle nuove API.