Angular 22.1 : les nouveautés à retenir (29 juillet 2026)

Angular 22.1 est disponible en version stable. Cette première version mineure depuis Angular 22.0 ne bouleverse pas la manière d'écrire une application. Elle améliore surtout la réactivité, le rendu serveur et la chaîne de build.

Le résumé court :

• linkedSignal peut contrôler les valeurs qui lui sont assignées ;
• le cache de transfert HTTP devient plus configurable ;
• le cache de build peut être partagé entre plusieurs worktrees Git ;
• le SSR comprend l'en-tête standard Forwarded ;
• les builds serveur profitent aussi de l'optimisation des chunks ;
• JSONP entre dans une phase de dépréciation.

linkedSignal peut contrôler les écritures

Un linkedSignal représente un état dérivé d'une autre donnée, mais qui reste modifiable. Par exemple, une liste de quantités autorisées peut fournir une valeur par défaut, tout en laissant l'utilisateur choisir une autre quantité.

Angular 22.1 ajoute l'option set. Elle intercepte les appels à .set() et .update() avant d'enregistrer la valeur. Le callback reçoit la valeur demandée et une fonction rawSet qui effectue réellement l'écriture.

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

const maximum = signal(10);

const quantity = linkedSignal({
  source: maximum,
  computation: (limit) => Math.min(1, limit),
  set: (value, rawSet) => {
    rawSet(Math.max(0, Math.min(value, maximum())));
  },
});

quantity.set(20);

console.log(quantity()); // 10

Ici, la quantité reste comprise entre zéro et la limite courante. Le setter personnalisé centralise cette règle : tous les consommateurs du Signal obtiennent le même comportement.

Il faut néanmoins éviter de transformer cette option en fourre-tout. Une validation métier complexe ou asynchrone reste mieux placée dans un service ou dans un formulaire. Le setter de linkedSignal convient surtout aux transformations synchrones et prévisibles : normaliser une valeur, la borner ou refuser un état impossible.

Le cache HTTP du SSR devient plus explicite

Lors du rendu serveur, Angular peut enregistrer le résultat de certaines requêtes HTTP dans la page envoyée au navigateur. Au démarrage, le client réutilise cette réponse au lieu d'effectuer immédiatement la même requête. C'est le transfer cache.

Par sécurité, Angular exclut normalement les échanges susceptibles de contenir des données privées ou de demander un traitement particulier. Angular 22.1 ajoute trois options à HttpTransferCacheOptions :

• includeRequestsWithAuthHeaders pour les requêtes contenant notamment Authorization ou Cookie ;
• includeRequestsWithCredentials pour les requêtes utilisant withCredentials ou certains modes credentials de Fetch ;
• includeNonCacheableRequests pour passer outre des directives comme no-store, private ou un en-tête de réponse Set-Cookie.

Ces options répondent à des architectures réelles, mais leur nom commençant par include doit être pris au sérieux. Les activer sans filtre peut incorporer une réponse propre à un utilisateur dans le HTML rendu. Il faut limiter précisément les URLs concernées et vérifier la politique de cache de l'application.

Le comportement par défaut reste prudent : ces requêtes sont exclues.

Des builds mieux partagés entre les worktrees Git

Un worktree Git permet d'ouvrir plusieurs branches du même dépôt dans des dossiers séparés. C'est pratique pour travailler sur un correctif tout en conservant une autre branche prête à être testée.

Jusqu'ici, chaque dossier pouvait accumuler son propre cache Angular. Angular CLI 22.1 sait partager le cache persistant entre les worktrees d'un même dépôt. Le premier build d'une branche reste nécessaire, mais les transformations déjà calculées dans un autre worktree peuvent être réutilisées.

Angular ajoute également un stockage SQLite de secours pour le cache. Cette solution est utilisée lorsque le mécanisme principal n'est pas adapté à l'environnement. Pour le développeur, l'effet attendu est simple : un cache plus robuste, sans nouvelle configuration obligatoire.

Rolldown et l'optimisation des chunks progressent

La chaîne de build Angular continue sa transition vers des outils plus rapides. En 22.1, l'optimisation des chunks utilise Rolldown par défaut, et cette optimisation est activée pour les builds serveur.

Un chunk est un fichier JavaScript produit lors du build. L'optimiseur cherche notamment les portions communes afin d'éviter de répéter le même code dans plusieurs fichiers. Sur une application SSR, ce travail peut réduire la duplication dans la sortie serveur.

La CLI migre aussi certains traitements internes de Babel vers oxc-parser et magic-string, notamment pour l'internationalisation. Ce sont surtout des changements d'implémentation : aucune réécriture du code applicatif n'est demandée. Leur intérêt est de préparer une chaîne de compilation plus rapide et plus homogène.

Autre détail utile pour les déploiements sécurisés : la CLI émet des identifiants de debug afin de rendre les empreintes SRI plus stables. La Subresource Integrity permet au navigateur de vérifier qu'un fichier chargé correspond bien à l'empreinte déclarée.

Le SSR comprend l'en-tête Forwarded

Une application SSR est souvent placée derrière un reverse proxy, un équilibreur de charge ou une plateforme cloud. Le serveur Angular ne voit alors pas toujours directement le protocole, l'hôte et l'adresse du client d'origine.

Angular SSR 22.1 prend en charge l'en-tête HTTP standard Forwarded. Il peut ainsi mieux reconstruire les informations de la requête initiale dans les infrastructures qui utilisent ce standard.

Cette prise en charge ne dispense pas de configurer les proxies de confiance. Un en-tête transmis directement par un client ne doit pas être considéré comme fiable si l'infrastructure ne le nettoie pas ou ne le remplace pas.

Des outils de migration et de diagnostic plus utiles

Angular 22.1 ajoute une migration de @Injectable() vers le nouveau décorateur @Service(). Elle permet d'automatiser les cas simples au lieu de modifier chaque service à la main.

Le Language Service sait désormais vérifier davantage de templates associés à des classes standalone non exportées. Autrement dit, certaines erreurs qui passaient auparavant hors du contrôle de l'éditeur peuvent être signalées plus tôt.

Le panneau Performance d'Angular DevTools gagne aussi des liens profonds vers les DevTools du navigateur. L'objectif est de passer plus facilement d'une observation Angular à la trace de performance correspondante.

Enfin, RouterLinkActive gère mieux les entrées null et undefined. C'est une petite amélioration, mais elle évite du code défensif dans les menus dont les liens sont calculés dynamiquement.

JSONP est déprécié

Angular 22.1 déprécie HttpClient.jsonp, HttpClientJsonpModule et les classes associées.

JSONP est une ancienne technique permettant de contourner les restrictions d'origine en chargeant une réponse comme un script. Les navigateurs et serveurs modernes utilisent CORS pour autoriser explicitement les requêtes entre origines.

Une dépréciation n'est pas une suppression immédiate : une application existante continue de fonctionner. En revanche, il faut prévoir de remplacer JSONP par une API HTTP classique configurée avec CORS.

Dans Angular DevKit, stringToFileBuffer et fileBufferToString sont également dépréciées au profit des APIs Web standard TextEncoder et TextDecoder. Ce changement concerne surtout les auteurs de builders et de schematics.

Comment passer à Angular 22.1 ?

Pour mettre à jour une application Angular 22 :

ng update @angular/[email protected] @angular/[email protected]

Comme pour toute mise à jour, effectuez l'opération dans une branche dédiée. Vérifiez le diff des migrations, lancez les tests et construisez les sorties navigateur et serveur. Les bibliothèques tierces doivent également déclarer leur compatibilité avec Angular 22.

Angular 22.1 est une version d'amélioration plus qu'une révolution. Le setter de linkedSignal est la nouveauté la plus visible dans le code applicatif. Le reste du travail se concentre sur des fondations moins spectaculaires, mais importantes : builds mieux mis en cache, SSR plus conforme aux standards et comportements HTTP plus explicites.

Sources

• Changelog du framework Angular 22.1.x
• Changelog d'Angular CLI 22.1.x
• Versions et calendrier de publication d'Angular
• RFC 7239 : en-tête HTTP Forwarded
• Métadonnées npm de @angular/core