Nouveautés de TypeScript

TypeScript publie plusieurs versions mineures par an, et chacune apporte de quoi écrire un code plus sûr ou plus court, ou fait apparaître des erreurs dans un code qui compilait. Ce cours ne recopie pas les notes de version : il retient, de la 5.0 à la 6.0, ce qui change la façon d'écrire du code applicatif, avec pour chaque nouveauté la version qui l'a apportée, lue dans les notes de version officielles. Il finit par TypeScript 7.0, le compilateur réécrit en Go sorti le 8 juillet 2026, et par la raison pour laquelle un projet Angular 22.1 reste en 6.0. Les exemples compilent avec tsc 6.0.3 en strict et s'exécutent sous Node 24 ; les options de compilation sont détaillées dans le cours Configuration et écosystème, et satisfies, arrivé en 4.9, dans Types et inférence.

Lire une version de TypeScript

Le numéro de version de TypeScript ne promet pas la compatibilité. Les notes de chaque version mineure depuis la 5.0 ont leur rubrique de changements cassants, « Breaking Changes » ou « Notable Behavioral Changes », parce qu'une vérification nouvelle est, par construction, une erreur de plus dans un code qui n'a pas bougé. La 5.6, par exemple, signale les tests dont le résultat se déduit de la syntaxe seule ; le fichier suivant compile sans un mot avec tsc 5.5 et échoue à partir de la 5.6.

interface Ligne {
  reference: string;
  libelle?: string;
}

const ligne: Ligne = { reference: 'USB-64' };

// + se lie plus fort que ?? : la ligne se lit ('Article : ' + ligne.libelle) ?? ligne.reference.
// Une concatenation n'est jamais nulle, et le repli ne sert jamais.
// const titre = 'Article : ' + ligne.libelle ?? ligne.reference;
// tsc 5.5 : aucune erreur, et l'execution affiche « Article : undefined ».
// tsc 5.6 et suivants, ici 6.0.3 :
// error TS2869: Right operand of ?? is unreachable because the left operand is never nullish.

const titre = 'Article : ' + (ligne.libelle ?? ligne.reference);
console.log(titre); // Article : USB-64

L'erreur signale un vrai défaut, et c'est tout l'intérêt de la mise à jour ; encore faut-il la choisir. Le web/package.json du site fixe ainsi "typescript": "~6.0.2" : le tilde admet les correctifs 6.0.x, pas la 6.1. Le tableau ci-dessous situe les nouveautés de ce cours, avec la date de publication sur npm de la première version stable de chaque ligne.

Des génériques qui infèrent ce qu'on attend

Les paramètres de type const

Un littéral passé à une fonction générique s'élargit comme partout ailleurs : ['creee', 'payee'] devient string[]. Une fonction qui devait dériver de sa liste le type des états n'en retient alors aucun, et laisse passer n'importe quelle chaîne.

// Un parcours de commande : un etat ne mene qu'a un etat situe plus loin.
function parcours<E extends readonly string[]>(etats: E) {
  return {
    peutPasser(depuis: E[number], vers: E[number]): boolean {
      return etats.indexOf(vers) > etats.indexOf(depuis);
    },
  };
}

// Le litteral s'elargit : E vaut string[], donc E[number] vaut string.
const commande = parcours(['creee', 'payee', 'expediee']);

// La faute de frappe compile, et la reponse est fausse sans un mot.
console.log(commande.peutPasser('creee', 'expedie')); // false

Avant la 5.0, la parade était d'écrire as const à chaque appel, au risque de l'oublier. Le modificateur const sur un paramètre de type déplace ce as const dans la déclaration : l'auteur de la fonction le décide une fois pour tous les appelants.

// TypeScript 5.0 : const sur le parametre de type. L'argument est infere comme
// s'il portait as const.
function parcours<const E extends readonly string[]>(etats: E) {
  return {
    peutPasser(depuis: E[number], vers: E[number]): boolean {
      return etats.indexOf(vers) > etats.indexOf(depuis);
    },
  };
}

// E vaut readonly ["creee", "payee", "expediee"].
const commande = parcours(['creee', 'payee', 'expediee']);

// commande.peutPasser('creee', 'expedie');
// error TS2345: Argument of type '"expedie"' is not assignable to parameter of type '"creee" | "payee" | "expediee"'.
console.log(commande.peutPasser('creee', 'expediee')); // true

La contrainte readonly string[] a une histoire. En 5.0 et 5.2, const inférait toujours un tuple readonly ; sous une contrainte modifiable, string[], ce tuple était refusé et l'inférence retombait sur la contrainte, comme le décrivent les notes de version 5.0. Depuis la 5.3 (pull request microsoft/TypeScript#55229), le compilateur infère alors un tuple modifiable, ["creee", "payee", "expediee"] : les deux contraintes donnent aujourd'hui la même union d'états. readonly reste le bon choix pour deux raisons : il donne le tuple dans toutes les versions depuis la 5.0, et il accepte un tableau déjà figé par as const, qu'une contrainte modifiable refuse avec TS2345.

NoInfer

Quand plusieurs arguments proposent chacun un candidat pour le même paramètre de type, TypeScript les réunit. C'est le plus souvent ce qu'on veut, sauf quand un argument doit appartenir à ce que décrivent les autres : une taille par défaut choisie parmi les tailles proposées.

// La taille par defaut doit etre l'une des tailles proposees.
function selecteur<T extends string>(tailles: readonly T[], parDefaut: T) {
  return { tailles, choisie: parDefaut };
}

// Les deux arguments proposent des candidats pour T, que TypeScript reunit :
// T vaut "S" | "M" | "L" | "XL", et la taille absente de la liste passe.
const selection = selecteur(['S', 'M', 'L'], 'XL');
console.log(selection.choisie); // XL

Le type utilitaire NoInfer<T>, apporté par la 5.4, masque une position à l'inférence sans rien changer au type : T se déduit des autres arguments, et l'argument masqué n'est plus que vérifié.

// TypeScript 5.4 : NoInfer<T> retire parDefaut de l'inference. T se deduit des
// seules tailles ; parDefaut est ensuite verifie contre le resultat.
function selecteur<T extends string>(tailles: readonly T[], parDefaut: NoInfer<T>) {
  return { tailles, choisie: parDefaut };
}

// selecteur(['S', 'M', 'L'], 'XL');
// error TS2345: Argument of type '"XL"' is not assignable to parameter of type '"S" | "M" | "L"'.
const selection = selecteur(['S', 'M', 'L'], 'M');
console.log(selection.choisie); // M

La 6.0 corrige un cas voisin. Une méthode écrite en syntaxe de méthode dans un littéral passé à une fonction générique, même avec tous ses paramètres annotés, a un this implicite : l'inférence la traitait comme dépendante du contexte et ne la lisait qu'après les autres arguments, si bien que l'ordre des propriétés pouvait laisser un paramètre voisin en unknown. Si elle n'utilise pas this, elle compte désormais comme une fonction ordinaire.

Un rétrécissement qui va plus loin

Le rétrécissement, présenté dans le cours Types et inférence, a longtemps été abandonné à l'entrée d'une fermeture pour un paramètre ou une variable let. La raison est prudente : un rappel peut s'exécuter plus tard, après une nouvelle affectation de la variable qu'il capture. Depuis la 5.4, le compilateur vérifie que la variable n'est plus affectée après la création de la fermeture, et garde alors le type restreint. La 5.5 étend le rétrécissement à un accès obj[cle], quand ni l'objet ni la clé ne changent entre le test et l'usage.

interface Ligne {
  reference: string;
  prix: number;
  quantite?: number;
}

const lignes: Ligne[] = [
  { reference: 'USB-64', prix: 12, quantite: 2 },
  { reference: 'SSD-1T', prix: 90 },
];

// TypeScript 5.4 : la fleche est creee apres la derniere affectation de devise,
// qui reste donc string dans la fleche. Avant la 5.4, elle y redevenait
// string | undefined.
function libelles(devise: string | undefined): string[] {
  if (devise === undefined) {
    devise = 'EUR';
  }
  return lignes.map((l) => `${l.reference} : ${l.prix} ${devise.toLowerCase()}`);
}

// Si une fonction imbriquee reaffecte la variable, n'importe quel rappel peut
// l'executer : le compilateur renonce au retrecissement dans toutes les fermetures.
function libellesPrudents(devise: string | undefined): string[] {
  if (devise === undefined) {
    devise = 'EUR';
  }
  const reinitialiser = () => {
    devise = undefined;
  };
  // return lignes.map((l) => devise.toLowerCase());
  // error TS18048: 'devise' is possibly 'undefined'.
  reinitialiser();
  return lignes.map((l) => (devise ?? 'EUR').toLowerCase());
}

// TypeScript 5.5 : champs[cle] se retrecit, ni champs ni cle ne changeant.
// Jusqu'a la 5.4, le test ne portait pas sur l'acces suivant.
function enMajuscules(champs: Record<string, unknown>, cle: string): string {
  return typeof champs[cle] === 'string' ? champs[cle].toUpperCase() : '';
}

console.log(libelles(undefined)); // [ 'USB-64 : 12 eur', 'SSD-1T : 90 eur' ]
console.log(libellesPrudents('USD'), enMajuscules({ ref: 'usb' }, 'ref')); // [ 'eur', 'eur' ] USB

La règle de la 5.4 reste prudente : il suffit qu'une fonction imbriquée, n'importe où dans la fonction, réaffecte la variable pour que toutes les fermetures la reprennent avec son type déclaré. La même version 5.5 déduit aussi un prédicat de type pour une fonction qui teste son paramètre, ce qui rend enfin utile filter pour retirer les undefined ; le cours Types et inférence le présente, avec ses limites.

Les décorateurs standard

TypeScript 5.0 implémente la proposition de décorateurs d'ECMAScript. Sans l'option experimentalDecorators, @ désigne désormais ces décorateurs standard, dont le contrat diffère de l'ancien : l'ancien recevait la cible, le nom et le descripteur de propriété, et modifiait ce descripteur ; le nouveau reçoit la valeur décorée et un objet de contexte, et rend éventuellement la valeur qui la remplace. Un décorateur écrit pour l'une des formes ne fonctionne en général pas avec l'autre.

// Un decorateur ecrit pour experimentalDecorators : il recoit la cible, le nom
// et le descripteur de la methode, et remplace descripteur.value.
function journaliser(cible: object, cle: string, descripteur: PropertyDescriptor): void {
  const methode = descripteur.value;
  descripteur.value = function (this: unknown, ...args: unknown[]) {
    console.log(`-> ${cle}(${args.join(', ')})`);
    return methode.apply(this, args);
  };
}

class Panier {
  lignes: string[] = [];

  // Sans "experimentalDecorators": true, @ designe un decorateur standard :
  // error TS1241: Unable to resolve signature of method decorator when called as an expression.
  //   The runtime will invoke the decorator with 2 arguments, but the decorator expects 3.
  @journaliser
  ajouter(reference: string): number {
    return this.lignes.push(reference);
  }
}

La forme standard se type entièrement : ClassMethodDecoratorContext décrit le contexte d'une méthode (son nom, static, private, addInitializer), et les paramètres génériques propagent la signature de la méthode décorée jusqu'à celle qui la remplace.

// Decorateur standard (TypeScript 5.0) : la methode et un contexte, et la
// methode de remplacement en retour.
function journaliser<This, Args extends unknown[], Retour>(
  methode: (this: This, ...args: Args) => Retour,
  contexte: ClassMethodDecoratorContext<This, (this: This, ...args: Args) => Retour>,
) {
  const nom = String(contexte.name);
  return function (this: This, ...args: Args): Retour {
    console.log(`-> ${nom}(${args.join(', ')})`);
    return methode.call(this, ...args);
  };
}

class Panier {
  lignes: string[] = [];

  @journaliser
  ajouter(reference: string): number {
    return this.lignes.push(reference);
  }
}

console.log(new Panier().ajouter('USB-64'));
// -> ajouter(USB-64)
// 1

La proposition standard laisse de côté deux usages de l'ancienne forme : elle ne permet pas de décorer un paramètre, et elle n'est pas compatible avec emitDecoratorMetadata, qui émettait les types des paramètres, dont se servent des bibliothèques d'injection. La 5.2 lui a ajouté ses propres métadonnées, contexte.metadata, sans types émis. Angular garde l'ancienne forme : le tsconfig.json que produit ng new (@schematics/angular 22.1.8) active experimentalDecorators, celui du site aussi, et @angular/core fournit encore @Inject(), un décorateur de paramètre de constructeur que la forme standard ne sait pas exprimer. L'option existe toujours dans TypeScript 7.0.

using et await using

Une ressource prise doit être rendue sur tous les chemins de sortie, y compris une exception ou un return anticipé. Le code écrit à la main l'oublie dès qu'un chemin a été ajouté après coup.

class Verrou {
  readonly nom: string;

  constructor(nom: string) {
    this.nom = nom;
    console.log(`prend ${nom}`);
  }

  rendre(): void {
    console.log(`rend ${this.nom}`);
  }
}

function reserver(reference: string): void {
  const verrou = new Verrou(`stock ${reference}`);
  if (reference === 'HDMI-2M') {
    throw new Error('rupture'); // sortie anticipee : rendre() n'est jamais appele
  }
  console.log('reserve');
  verrou.rendre();
}

try {
  reserver('HDMI-2M');
} catch (e) {
  console.log((e as Error).message);
}
// prend stock HDMI-2M
// rupture

TypeScript 5.2 prend en charge la gestion explicite des ressources d'ECMAScript, qu'un développeur C# reconnaîtra : Disposable et AsyncDisposable jouent le rôle d'IDisposable et d'IAsyncDisposable, et using celui de using var. La méthode de libération a pour nom un symbole, Symbol.dispose, qu'aucune méthode existante ne peut porter par hasard. Les ressources sont rendues à la sortie du bloc, dans l'ordre inverse de leur acquisition ; si la libération lève à son tour, l'erreur d'origine n'est pas perdue, elle est enveloppée avec la nouvelle dans un SuppressedError.

// tsconfig.json : "lib": ["es2025", "esnext.disposable", "dom"] (ou "esnext").
class Verrou implements Disposable {
  readonly nom: string;

  constructor(nom: string) {
    this.nom = nom;
    console.log(`prend ${nom}`);
  }

  [Symbol.dispose](): void {
    console.log(`rend ${this.nom}`);
  }
}

// TypeScript 5.2 : chaque using est libere a la sortie du bloc, quelle qu'elle
// soit, dans l'ordre inverse des acquisitions.
function reserver(reference: string): void {
  using panier = new Verrou('panier');
  using stock = new Verrou(`stock ${reference}`);
  if (reference === 'HDMI-2M') {
    throw new Error('rupture');
  }
  console.log('reserve');
}

try {
  reserver('HDMI-2M');
} catch (e) {
  console.log((e as Error).message);
}
// prend panier
// prend stock HDMI-2M
// rend stock HDMI-2M
// rend panier
// rupture

La version asynchrone suit la même règle avec await using, et DisposableStack accumule des libérations ponctuelles sans écrire de classe.

// Meme tsconfig.json. await using attend Symbol.asyncDispose ; DisposableStack
// rassemble des liberations ecrites sur place, sans classe dediee.
class Connexion implements AsyncDisposable {
  async [Symbol.asyncDispose](): Promise<void> {
    console.log('ferme la connexion');
  }
}

async function synchroniser(): Promise<void> {
  await using connexion = new Connexion();
  using pile = new DisposableStack();
  pile.defer(() => console.log('vide le cache'));
  console.log('synchronise');
}

await synchroniser();
// synchronise
// vide le cache
// ferme la connexion
export {};

Deux réglages conditionnent l'ensemble. Les types viennent de esnext.disposable : avec la lib par défaut de la 6.0, Disposable est inconnu (TS2304) et Symbol.dispose aussi, avec l'erreur TS2550 qui propose de passer lib à esnext. Et using n'appartient pas à la cible par défaut, es2025 : tsc le réécrit alors avec des fonctions d'aide, qui exigent que Symbol.dispose existe à l'exécution. Node 24 le fournit, et exécute aussi using tel quel quand la cible est esnext.

Du TypeScript qu'on peut effacer

Node exécute des fichiers .ts depuis la version 23.6 sans option : il remplace les annotations par des espaces et exécute le reste, sans vérifier aucun type. La méthode ne vaut que pour une syntaxe effaçable, dont le retrait laisse un JavaScript valide. Quelques constructions de TypeScript produisent du code au lieu de disparaître : enum, namespace qui contient du code, propriétés de paramètre, import x = require() et export =. Node les refuse, et tsc ne dit rien tant qu'on ne le lui demande pas.

// commande.ts, execute par node commande.ts (Node 24).
enum Statut {
  Creee,
  Payee,
}

class Commande {
  // Proprietes de parametre : le constructeur recoit des affectations qu'aucune
  // ligne du fichier n'ecrit.
  constructor(
    public readonly reference: string,
    public statut: Statut,
  ) {}
}

const commande = new Commande('C-001', Statut.Payee);
console.log(commande.reference, Statut[commande.statut]);

// Avec "erasableSyntaxOnly": true :
// commande.ts(2,6): error TS1294: This syntax is not allowed when 'erasableSyntaxOnly' is enabled.
// commande.ts(11,5): error TS1294: This syntax is not allowed when 'erasableSyntaxOnly' is enabled.
// commande.ts(12,5): error TS1294: This syntax is not allowed when 'erasableSyntaxOnly' is enabled.
// Sans l'option, tsc ne dit rien ; Node refuse le fichier :
// SyntaxError [ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX]: TypeScript enum is not supported in strip-only mode

L'option erasableSyntaxOnly, apportée par la 5.8, fait signaler ces constructions par tsc, dans l'éditeur, avant que Node ne les refuse. Chacune a un équivalent effaçable, souvent plus proche du JavaScript qui s'exécute réellement.

// Un objet as const et l'union de ses valeurs remplacent l'enum ; les champs
// sont declares et affectes en toutes lettres.
const Statut = {
  Creee: 'creee',
  Payee: 'payee',
} as const;
type Statut = (typeof Statut)[keyof typeof Statut]; // "creee" | "payee"

class Commande {
  readonly reference: string;
  statut: Statut;

  constructor(reference: string, statut: Statut) {
    this.reference = reference;
    this.statut = statut;
  }
}

const commande = new Commande('C-001', Statut.Payee);
console.log(commande.reference, commande.statut); // C-001 payee

// Retirer les annotations laisse un JavaScript valide : tsc l'accepte avec
// erasableSyntaxOnly, et node commande.ts l'execute tel quel.

L'option complète verbatimModuleSyntax, présentée dans le cours Configuration et écosystème : l'une garantit que les imports s'effacent fichier par fichier, l'autre que le reste du code le peut aussi. Un programme exécuté ainsi importe ses fichiers avec leur extension réelle, './panier.ts' : allowImportingTsExtensions l'autorise quand tsc n'émet rien, et rewriteRelativeImportExtensions, ajoutée par la 5.7, le réécrit en './panier.js' quand il émet le JavaScript.

TypeScript 7.0, le compilateur natif

TypeScript 7.0 est un compilateur porté en Go, et son annonce du 8 juillet 2026 fait état de builds complets 8 à 12 fois plus rapides. Le paquet s'appelle toujours typescript et le binaire tsc. La vérification des types se parallélise : quatre vérificateurs par défaut, un nombre que règle l'option expérimentale --checkers. Sur la machine de rédaction, en septembre 2026, la vérification de ce site sans émission est passée de quelques secondes avec tsc 6.0.3 à moins d'une seconde avec tsc 7.0.2, un rapport de 3 à 12 selon les exécutions.

Ce qui change pour l'utilisateur

Le langage change peu. L'annonce cite l'inférence depuis les template literal types, qui découpe désormais une chaîne en points de code Unicode et non plus en unités UTF-16, et une analyse du JavaScript annoté en JSDoc largement refaite. La configuration, elle, suit la 6.0 jusqu'au bout : ses dépréciations, détaillées dans le cours Configuration et écosystème, deviennent des options retirées, que ignoreDeprecations n'excuse plus. tsc 6.0.3 accepte le tsconfig.json suivant sans un mot ; tsc 7.0.2 le refuse.

{
  "compilerOptions": {
    "target": "es5",
    "moduleResolution": "node",
    "baseUrl": "./src",
    "ignoreDeprecations": "6.0",
    "noEmit": true
  },
  "include": ["src"]
}

Sur les exemples de ce cours, les messages restent ceux de la 6.0, à un détail près : l'ordre des membres d'une union ne dépend plus de l'ordre dans lequel le compilateur rencontre les types, et n'est donc plus toujours l'ordre d'écriture. Une capture de message comparée d'une version à l'autre peut différer sans que le code ait bougé ; l'option --stableTypeOrdering de la 6.0 reproduit cet ordre. Enfin, l'API de la 6.0, ts.createProgram et le reste, a disparu. Le paquet livre à la place une API expérimentale et différente sous typescript/unstable/*, sans garantie de stabilité ; l'annonce dit que la 7.0 ne livre pas d'API et en prévoit une nouvelle pour la 7.1. Les sorties ci-dessous sont celles de tsc 7.0.2.

# Le tsconfig.json ci-dessus, compile par tsc 7.0.2 :
tsconfig.json(3,15): error TS5108: Option 'target=ES5' has been removed. Please remove it from your configuration.
tsconfig.json(4,25): error TS5108: Option 'moduleResolution=node10' has been removed. Please remove it from your configuration.
tsconfig.json(5,5): error TS5102: Option 'baseUrl' has been removed. Please remove it from your configuration.
  Use '"paths": {"*": ["./src/*"]}' instead.

# L'appel fautif de la section NoInfer, selecteur(['S', 'M', 'L'], 'XL') :
# tsc 6.0.3 : ... parameter of type '"S" | "M" | "L"'.
# tsc 7.0.2 : ... parameter of type '"L" | "M" | "S"'.
# L'ordre ne depend plus de celui dans lequel le compilateur rencontre les
# types ; tsc 6.0.3 --stableTypeOrdering affiche deja le second.

# Le point d'entree du paquet ne rend que sa version : ts.createProgram et le
# reste de l'API 6.0 ont disparu.
node -e "console.log(Object.keys(require('typescript')))"
[ 'version', 'versionMajorMinor' ]
# Son package.json exporte en revanche une API experimentale, differente
# (classes API, Program, Checker...) : ./unstable/sync, ./unstable/async,
# ./unstable/ast et leurs voisins.

Pourquoi Angular 22.1 reste en 6.0

Le compilateur d'Angular n'appelle pas tsc : il se sert de l'API de TypeScript pour construire le programme, analyser les composants et faire valider par le compilateur TypeScript les expressions des templates. Sans l'API de la 6.0, il n'a rien à appeler. @angular/compiler-cli 22.1 déclare donc "typescript": ">=6.0 <6.1" dans ses peerDependencies, et vérifie la version avant de construire le programme. Lever ce contrôle, par l'option disableTypeScriptVersionCheck, ne mènerait nulle part : avec le paquet 7.0.2, le compilateur échoue dès la lecture du tsconfig.

# @angular/compiler-cli 22.1.7 declare dans son package.json :
#   "peerDependencies": { "@angular/compiler": "22.1.7", "typescript": ">=6.0 <6.1" }
# Avant de construire le programme par ts.createProgram, son code verifie la
# version (sauf avec l'option disableTypeScriptVersionCheck) :
#   throw new Error(`The Angular Compiler requires TypeScript >=${minVersion} and <${maxVersion} but ${version} was found instead.`);

# ngc, avec l'import de typescript redirige vers le paquet 7.0.2, n'atteint pas
# ce controle : il echoue des la lecture du tsconfig (chemin abrege).
TypeError: ts2.parseCommandLine is not a function
    at readCommandLineAndConfiguration (file:///.../@angular/compiler-cli/bundles/chunk-P3PYM3ZL.js:303:23)

L'annonce de la 7.0 le prévoit : la vérification des templates d'Angular n'utilisera probablement pas encore la 7.0. Elle propose aux projets Angular de combiner les deux, la 7.0 pour une vérification rapide de tout le projet en ligne de commande, la 6.0 pour l'éditeur, et publie pour cela un paquet de compatibilité, @typescript/typescript6, qui fournit l'API 6.0 et un binaire tsc6. Selon l'annonce, la déclaration suivante installe les deux côte à côte : typescript désigne alors le paquet de compatibilité, que lisent les outils, et tsc est celui de la 7.0.

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

Pour ng build et ng serve, la 6.0 reste la seule version admise, tant que le compilateur d'Angular dépend de son API.