Angular 22, sorti le 3 juin 2026, est la dernière version stable du cadre au moment d’écrire ces lignes. Par rapport à Angular 21 (novembre 2025, qui avait fait du sans zone la valeur par défaut et avait introduit Signal Forms comme API expérimentale), cette version consolide dans un format stable et prêt pour la production tout ce qui était encore en version préliminaire pour les développeurs : Formulaires de signal, L'API de ressources et Angular Aria deviennent officiellement utilisables en production, les valeurs par défaut de certains Les API évoluent vers des modèles plus modernes et une première couche d'outils d'IA intégrée à la CLI arrive.
Comme toujours avec une version récente, vérifiez la version exacte installée et les notes de version
officiel avant de planifier une mise à niveau en production : ng version et npm view
@angular/core versions renvoient l'état réel de votre projet et du registre npm,
plus fiable que n’importe quel résumé statique.
Aperçu rapide
- Formes de signal stables : Le système de formulaires basé sur le signal, expérimental dans la v21, est désormais prêt pour la production.
- Resource API stable :
resource(),rxResource()ethttpResource()passent d'expérimental à stable. - Angular Aria stable : Package
@angular/ariapour le passage du modèle d'accessibilité de l'aperçu pour les développeurs à la disponibilité générale. - OnPush par défaut : les nouveaux composants utilisent
OnPushau lieu deEagerpour la détection des changements. - Récupérer l'API par défaut pour HttpClient : remplace
- Outils d'IA dans la CLI : compétences angulaires et prise en charge expérimentale de WebMCP pour les agents de codage.
- TypeScript 6 requis : exigence minimale augmentée, le nœud 20 n'est plus pris en charge (nœud 22 minimum).
Fonctionnalité détaillée
Formes de signaux : d'expérimental à stable
Signal Forms combine le typage fort des formulaires réactifs traditionnels avec une réactivité granulaire
de Signal, éliminant une grande partie du passe-partout de FormGroup/FormControl.
Dans cette version, les validateurs minDate()/maxDate() arrivent, anti-rebond natif
sur les événements de flou, et une méthode getError() pour récupérer les erreurs ciblées sans
parcourir toute l’arborescence du formulaire.
// Signal Forms — validazione con debounce sul blur, stabile da v22
const form = signalForm({
email: field('', { validators: [required(), email()] }),
});
debounce(form.email, 'blur', 300);
API de ressources : récupération de données réactives
// httpResource() — fetching dichiarativo, nessun switchMap manuale
userResource = httpResource(() => `/api/users/${this.userId()}`);
// userResource.value(), userResource.isLoading(), userResource.error() sono Signal reattivi
Nouveau dans cette version : une méthode chain() pour composer des ressources mutuellement dépendantes
de l'autre sans imbrication manuelle effect(), et prise en charge du cache côté SSR via
une option id, utile pour éviter la double récupération entre le serveur de rendu et le client d'hydratation.
OnPush par défaut et récupérer l'API par défaut
// 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 utilise l'API Fetch au lieu de XMLHttpRequest sans avoir besoin
withFetch() explicite (désormais obsolète pour suppression) ; soyez prudent si votre
le code dépend de reportProgress pour le téléchargement, car le rapport de progression dans
le téléchargement n'est pas pris en charge par l'implémentation Fetch et doit être géré avec les nouveaux
reportUploadProgress/reportDownloadProgress.
@Service Décorateur et 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 : l'accessibilité en tant qu'infrastructure
@angular/aria, désormais en disponibilité générale, fournit des directives qui gèrent
automatiquement les attributs ARIA, la navigation au clavier et la gestion du focus pour les modèles composés
(liste déroulante, onglet, arbre) — le développeur se concentre sur la conception visuelle et la logique métier, et non sur la conception visuelle et la logique métier.
sur la réimplémentation manuelle du guide des pratiques de création ARIA pour chaque composant.
Modifications révolutionnaires et dépréciations
- TypeScript 6 requis : 5.9 et versions antérieures ne sont plus prises en charge — mettez à jour TypeScript avant d'exécuter
ng update. - Nœud 20 supprimé : le nœud minimum pris en charge est le nœud 22 (nœud 26 pris en charge).
toucheddans les formes de signal modifiées : du modèle à la paire d'entrée/sortie (touchedentrée,touch()sortie) — impact direct sur le code qui lu/écrittouchécomme modèle.markAsTouched()marque désormais les descendants par défaut : utilisez{ skipDescendants: true }pour conserver le comportement précédent si votre code le supposait.- Router :
canMatchnécessite un troisième paramètre obligatoire (currentSnapshot) — les gardes existantes doivent être mises à jour dans la signature. paramsInheritanceStrategymaintenant'always'par défaut (était'emptyOnly') : Vérifiez si votre dépendance est acheminée sur l'ancien comportement implicite.- Le chaînage facultatif dans les modèles modifie la sémantique :
project?.authorrenvoie désormaisundefinedau lieu denullsur les valeurs nulles, en s'alignant sur TypeScript. withIncrementalHydration()obsolète car il s'agit désormais du SSR par défaut ; utilisezwithNoIncrementalHydration()si vous avez explicitement besoin de l'ancien comportement.
Outillage et construction
# 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 reste l'optimiseur par défaut, mais Rolldown est disponible en option via
NG_BUILD_CHUNKS_ROLLDOWN pour ceux qui souhaitent bénéficier de temps de construction encore plus réduits.
La variable d'environnement PORT a désormais priorité sur l'indicateur --port pour le développement.
serveur, utile pour les configurations CI/CD conteneurisées.
Performances et offre groupée
OnPush par défaut réduit déjà le nombre de cycles de détection de modifications inutiles à
démarrez à partir de nouveaux projets échafaudés, sans avoir besoin de configuration manuelle. L'optimisation de
Le morceau activé par défaut dans la version de production réduit encore davantage le bundle initial par rapport
aux versions précédentes. Mesurez toujours avant/après avec des instruments standards :
ng build --configuration production --stats-json
npx webpack-bundle-analyzer dist/*/stats.json
npx lighthouse http://localhost:4200 --view
Gestion de l'État et réactivité
Avec Signal Forms et Resource API tous deux stables, le modèle recommandé pour le nouveau code est désormais
Signal d'abord : état local avec signal()/computed(), récupération de données avec
resource()/httpResource(), formulaire avec formulaires de signal. RxJS reste entièrement
pris en charge et nécessaire pour les flux complexes (WebSockets, plusieurs événements combinés), mais n'est plus le
valeur par défaut implicite pour chaque nouveau composant. Nouveauté expérimentale dans cette version : debounded(),
une fonction qui crée une version anti-rebond d'un Signal renvoyant un objet Resource.
// debounced() — sperimentale, debounce di un Signal senza RxJS
const query = signal('');
const debouncedQuery = debounced(query, { delay: 300 });
Rendu et bord côté serveur
L'hydratation incrémentielle est désormais le comportement SSR par défaut (plus opt-in via
withIncrementalHydration(), qui en fait est obsolète précisément parce qu'il est superflu).
provideServerRendering() accepte désormais un objet options, y compris
maxResponseBodySize pour limiter la taille de la réponse rendue côté serveur —
utile sur les plates-formes périphériques avec des limites de charge utile strictes par fonction unique.
// provideServerRendering con opzioni — utile su piattaforme edge con limiti di response size
provideServerRendering({ maxResponseBodySize: 5_000_000 });
Compatibilité et dépendances
| Angular | TypeScript | Node | Note |
|---|---|---|---|
| 21 | 5.6+ | 20/22 | Zoneless par défaut, formes de signaux expérimentaux |
| 22 | 6.0 minimum | 22/26 (20 supprimés) | Formulaires de signal/API de ressources/Aria stable |
Pour Angular Material, NgRx et autres bibliothèques de l'écosystème, vérifiez toujours la compatibilité
déclaré dans les peerDependencies du package spécifique avant la mise à niveau :
npm view @angular/material peerDependencies. Les bibliothèques qui dépendent fortement de
Les FormControl/FormGroup traditionnels restent compatibles — Formes de signal
coexiste avec les anciennes API réactives/pilotées par des modèles, ne les remplace pas de force.
Plan de migration et opérationnel
# 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
Liste de contrôle minimale avant la mise à niveau : TypeScript déjà à 6.x, Node déjà à 22+, branche dédiée, build et test vert comme ligne de base. Après la mise à jour, exécutez l'intégralité de la suite de tests et une version de production complète avant de procéder à toute adoption facultative (Signal Forms, Aria) sur les composants existants — le Les mises à niveau de versions et l'adoption de nouvelles API sont deux activités distinctes, elles ne doivent pas être combinées en une seule. même engagement. Pour la restauration, la balise Git de pré-mise à niveau reste le mécanisme le plus rapide et le plus fiable.
Tests et assurance qualité
// 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 dispose désormais d'un support natif pour Zone.js via zone.js/plugins/vitest-patch, et le
la migration automatique migrate-karma-to-vitest couvre la plupart des projets Karma
existant; pour ceux qui ont déjà migré vers Jasmine/Vitest, le flag --fake-async sur la migration
refactor-jasmine-vitest couvre les modèles de test asynchrones basés sur une minuterie.
Sécurité et meilleures pratiques
Aucune modification par défaut liée aux cookies ou au CSP dans cette version spécifique, mais la modification de Fetch
L'API pour HttpClient vaut le détour : si votre application dépend de comportements
spécifique à XMLHttpRequest (par exemple, en-têtes personnalisés sur les requêtes d'origine croisée), testez explicitement i
les flux d'authentification après la mise à niveau. Les bonnes pratiques restantes (HttpOnly/SameSite sur les cookies
session, CSP restrictif) ne changent pas et doivent être maintenus quelle que soit la version d'Angular.
Cas d'utilisation
Cas 1 : Tableau de bord d'entreprise avec des formulaires complexes
Un tableau de bord d'entreprise avec plus de 40 formulaires répartis sur différents modules a adopté Signal Forms sui nouveaux formulaires de fonctionnalités après la mise à niveau vers la v22, conservant les anciens formulaires sur les formulaires réactifs traditionnels grâce à la pleine coexistence des deux API. Résultat : un passe-partout réduit d'environ 30% sur les neufs formulaire, validation avec anti-rebond natif qui a éliminé le code anti-rebond manuscrit personnalisé sur RxJS précédemment.
Cas 2 : Application avec des exigences d'accessibilité strictes
Une application publique soumise aux exigences WCAG AA a remplacé l'implémentation personnalisée de
combobox et onglet (avec gestion ARIA écrite manuellement) avec @angular/aria après le
stabilisation dans la v22. Résultat : audit d'accessibilité automatique réussi sans intervention manuelle
ajout sur les modèles migrés, réduction du code spécifique de gestion du focus/clavier pour
composante d’environ 200 lignes au total.
FAQ
Devez-vous immédiatement migrer tous les formulaires vers Signal Forms ?
Non, Signal Forms coexiste avec les anciens formulaires réactifs/pilotés par des modèles ; la migration peut être progressive et opportuniste.
OnPush par défaut casse-t-il les composants existants ?
Non, la valeur par défaut s'applique uniquement aux nouveaux composants sans changeDetection explicite ; les composants existants maintiennent la stratégie déjà déclarée.
Dois-je mettre à niveau Node avant de mettre à niveau Angular ?
Oui, Node 20 n'est plus pris en charge dans la v22 - veuillez vérifier et mettre à jour Node vers 22+ avant d'exécuter ng update.
L'API Fetch interrompt-elle par défaut les appels HTTP existants ?
Dans la plupart des cas non, mais vérifiez le rapport de progression du téléchargement, qui nécessite les nouvelles options dédiées au lieu de l'ancien reportProgress.
Angular Aria remplace le matériau angulaire ?
Non, ils sont complémentaires : Aria propose des modèles d'accessibilité comportementale, Material fournit des composants visuels déjà stylisés.
Que se passe-t-il si je ne mets pas à niveau TypeScript vers la version 6 ?
ng update vers la v22 échouera ou signalera une incompatibilité : TypeScript 6 est une exigence obligatoire et non facultative.
Le Vitest remplace-t-il nécessairement le Karma ?
Pas immédiatement requis, mais Karma est obsolète dans l'écosystème Angular ; la migration automatique rend le passage à Vitest à faible risque.
Les outils AI/MCP sont-ils nécessaires pour utiliser Angular 22 ?
Non, il est facultatif et conçu pour ceux qui utilisent des agents de codage assistés par IA ; n'a pas d'impact sur le fonctionnement standard de l'application.
Comment vérifier
- Vérifier la version et les dépendances :
version ngetnpm obsolète. - Build de production complète :
ng build --configuration production. - Exécutez l'intégralité de la suite de tests :
ng test(ouvitest runsi déjà migré). - Test de fumée manuel sur les flux critiques (authentification, formulaires principaux) après mise à niveau.
- Tests E2E complets :
npx cypress runou équivalent. - Vérifiez la taille et les performances du bundle : analyseur de bundle plus
phare npx http://localhost:4200, par rapport à la référence de pré-mise à niveau.
Conclusion
Angular 22 n'introduit pas tant un changement de paradigme qu'une consolidation : les API basées sur le signal sont nées dans les versions précédentes (Signal Forms, Resource API) deviennent enfin stables et prêts pour production, les valeurs par défaut évoluent vers des patterns plus performants (OnPush, Fetch API), et un premier arrive couche d'outils conçue pour le développement assisté par l'IA. Pour la plupart des projets, la mise à niveau à partir de la v21 présente un faible risque si TypeScript et Node sont déjà à jour ; l'adoption de nouveaux Cependant, l'API reste facultative et peut se dérouler progressivement après la mise à niveau de la version.
Voulez-vous une liste de contrôle de migration détaillée pour votre projet ou une évaluation de l'effort de mise à niveau ? Demander un audit technique : en quelques heures d'analyse il est possible estimez les risques, les changements importants liés à votre base de code et les priorités d'adoption des nouvelles API.