TypeScript 5.x : les nouveautés essentielles

L'operateur satisfies (TS 4.9+)

L'operateur satisfies resout un probleme classique : valider qu'une valeur respecte un type tout en conservant le type infere le plus precis possible. Avant son introduction, on etait oblige de choisir entre securite (annotation de type) et precision (inference automatique).

Le probleme avant satisfies

Avec une annotation classique, TypeScript elargit le type et perd les informations precises sur chaque propriete :

// Avant satisfies : annotation de type classique
// TypeScript connait le type de 'colors', mais perd les details de chaque valeur
const colors: Record<string, string | [number, number, number]> = {
  rouge: '#ff0000',
  vert:  [0, 255, 0],
};

// Erreur : TypeScript ne sait plus que 'rouge' est specifiquement un string
// La methode toUpperCase() n'est pas accessible sans assertion de type
colors.rouge.toUpperCase();
// Erreur TS : Property 'toUpperCase' does not exist on type 'string | [number, number, number]'

La solution avec satisfies

L'operateur satisfies verifie la conformite au type sans ecraser le type infere :

// Avec satisfies : TypeScript valide la conformite ET conserve les types precis
const colors = {
  rouge: '#ff0000',         // type infere conserve : string
  vert:  [0, 255, 0],       // type infere conserve : [number, number, number]
} satisfies Record<string, string | [number, number, number]>;

// TypeScript sait maintenant que 'rouge' est un string : OK
colors.rouge.toUpperCase(); // Resultat : 'FF0000'

// TypeScript sait que 'vert' est un tableau numerique : OK
colors.vert[0]; // Resultat : 0

// satisfies detecte aussi les erreurs a la declaration :
const wrong = {
  bleu: true, // Erreur TS : boolean n'est pas string | [number, number, number]
} satisfies Record<string, string | [number, number, number]>;

Cas d'usage avec Angular : configuration de routes

import { Routes } from '@angular/router';

// satisfies verifie que chaque route respecte le type Routes
// tout en conservant le type precis de chaque propriete 'data'
const APP_ROUTES = [
  {
    path: 'dashboard',
    // Chargement paresseux du composant Dashboard
    loadComponent: () => import('./dashboard/dashboard.component')
      .then(m => m.DashboardComponent),
    // La propriete data reste typee precisement
    data: { title: 'Dashboard', requiresAuth: true },
  },
  {
    path: 'login',
    // Chargement paresseux du composant Login
    loadComponent: () => import('./auth/login.component')
      .then(m => m.LoginComponent),
    data: { title: 'Connexion', requiresAuth: false },
  },
] satisfies Routes;
// TypeScript valide la conformite au type Routes
// et conserve les types precis de data.title (string) et data.requiresAuth (boolean)

Const type parameters (TS 5.0)

TypeScript 5.0 introduit les const type parameters pour les fonctions generiques. Cette fonctionnalite permet d'inferer des tuples et tableaux literaux constants au lieu de types elargis comme string[], sans que l'appelant ait besoin d'ecrire as const.

Le probleme d'inference avec les generiques

Sans const, TypeScript elargit l'inference des valeurs litterales vers leur type general :

// Sans const sur le type parameter : TypeScript infere string[], pas un tuple precis
function createRoute<T extends string[]>(paths: T): T {
  return paths;
}

// L'inference produit string[] (type trop large)
const routes = createRoute(['home', 'about', 'contact']);
// Type infere : string[]  — la liste exacte des chemins est perdue !
// L'autocompletion ne sait pas que seules ces 3 valeurs sont valides

La solution avec const sur le type parameter

// Avec 'const' sur le type parameter : inference d'un tuple literal precis
function createRoute<const T extends string[]>(paths: T): T {
  return paths;
}

// TypeScript infere maintenant le tuple readonly exact
const routes = createRoute(['home', 'about', 'contact']);
// Type infere : readonly ['home', 'about', 'contact']
// Autocompletion et verification des valeurs disponibles precisement

Application pratique : factory de formulaire typee

import { FormGroup, FormControl } from '@angular/forms';

// Factory generique avec const type parameter
// TypeScript connait exactement les cles disponibles dans le formulaire retourne
function buildForm<const T extends Record<string, unknown>>(fields: T) {
  // Cree un FormControl pour chaque champ passe en parametre
  const controls = Object.fromEntries(
    Object.entries(fields).map(([key, value]) => [key, new FormControl(value)])
  );
  return new FormGroup(controls as any);
}

// Le type infere inclut les cles exactes 'email', 'password', 'rememberMe'
const loginForm = buildForm({
  email:      '',      // FormControl initialise a chaine vide
  password:   '',      // FormControl initialise a chaine vide
  rememberMe: false,   // FormControl initialise a false
});
// loginForm.controls.email est accessible avec autocompletion precise

Using et await using (TS 5.2)

TypeScript 5.2 introduit les declarations using et await using, inspirees des gestionnaires de contexte Python et des using statements C#. Elles garantissent la liberation automatique d'une ressource (connexion, fichier, listener) en fin de bloc, meme en cas d'exception.

Le probleme de la gestion manuelle des ressources

Sans using, liberer des ressources correctement demande une gestion manuelle via try/finally :

// Avant using : gestion manuelle avec try/finally
async function exportData(): Promise<User[]> {
  const connection = await openDatabaseConnection();
  try {
    // Execution de la requete
    const data = await connection.query('SELECT * FROM users');
    return processData(data);
  } finally {
    // La fermeture DOIT etre dans finally pour etre garantie meme en cas d'erreur
    await connection.close();
  }
}
// Probleme : le pattern try/finally est facile a oublier et alourdit le code

Symbol.dispose et Symbol.asyncDispose

Pour etre compatible avec using, un objet doit implementer Symbol.dispose (synchrone) ou Symbol.asyncDispose (asynchrone). TypeScript 5.2 fournit les types correspondants dans lib.es2022.d.ts et au-dela.

// Implementer Symbol.dispose pour une ressource synchrone
class FileWriter {
  private handle: number;

  constructor(path: string) {
    // Ouvre le fichier et stocke le handle systeme
    this.handle = openFileSync(path);
  }

  write(data: string): void {
    // Ecrit les donnees dans le fichier ouvert
    writeSync(this.handle, data);
  }

  // Cette methode est appelee automatiquement par 'using' en fin de bloc
  // Elle sera invoquee meme si une exception est levee dans le bloc
  [Symbol.dispose](): void {
    closeFileSync(this.handle);
    console.log('Fichier ferme automatiquement par using');
  }
}

// Utilisation avec using : liberation automatique garantie
function writeReport(): void {
  using writer = new FileWriter('./rapport.txt');
  // [Symbol.dispose] sera appele a la sortie du bloc, meme en cas d'erreur
  writer.write('Rapport genere le ' + new Date().toISOString());
}
writeReport();
// La fermeture du fichier est garantie, sans try/finally explicite

await using pour les ressources asynchrones

// Implementer Symbol.asyncDispose pour une connexion asynchrone
class DatabaseConnection {
  constructor(private client: DbClient) {}

  async query<T>(sql: string): Promise<T[]> {
    // Execute la requete SQL et retourne les resultats types
    return this.client.execute<T>(sql);
  }

  // Appelee automatiquement par 'await using' : fermeture asynchrone garantie
  async [Symbol.asyncDispose](): Promise<void> {
    await this.client.disconnect();
    console.log('Connexion fermee proprement');
  }
}

// await using garantit la fermeture asynchrone en sortie de bloc
async function getUserList(): Promise<User[]> {
  const client = await createDbClient(DB_URL);
  // La connexion sera fermee automatiquement a la fin du bloc
  await using db = new DatabaseConnection(client);

  // Si une exception est levee ici, Symbol.asyncDispose est quand meme appele
  return await db.query<User>('SELECT * FROM users WHERE active = 1');
  // db[Symbol.asyncDispose]() appele automatiquement ici
}

Integration Angular : contextes adaptes

// Note : dans les composants Angular, preferez takeUntilDestroyed() ou DestroyRef
// using est particulierement adapte dans :
// - les services sans lifecycle Angular
// - les scripts Node.js (scripts de build, migrations)
// - les tests unitaires (setup/teardown de ressources)

// Exemple : test unitaire avec using pour le teardown automatique
it('should process user data', async () => {
  // La connexion de test est fermee automatiquement apres le test
  await using testDb = new TestDatabaseConnection(TEST_DB_URL);

  const users = await testDb.query<User>('SELECT * FROM test_users');
  expect(users.length).toBeGreaterThan(0);
  // testDb est libere ici automatiquement, proprement
});

verbatimModuleSyntax (TS 5.0)

L'option verbatimModuleSyntax introduite dans TypeScript 5.0 remplace les anciennes options importsNotUsedAsValues et preserveValueImports. Elle impose une regle simple et claire : si vous importez uniquement un type, vous devez ecrire import type explicitement.

Pourquoi cette option existe

Sans verbatimModuleSyntax, TypeScript peut effacer silencieusement des imports lors de la compilation. Des outils comme esbuild, Vite ou le compilateur Angular ne font pas d'analyse semantique complete : ils s'appuient sur la syntaxe pour savoir si un import est une valeur ou un type. Des imports ambigus peuvent generer des modules incorrects en production.

Activer verbatimModuleSyntax dans tsconfig.json

// tsconfig.json — activation de verbatimModuleSyntax
{
  "compilerOptions": {
    "verbatimModuleSyntax": true,
    // Cette option remplace et rend obsoletes :
    // "importsNotUsedAsValues": "error"  (deprecated depuis TS 5.0)
    // "preserveValueImports": true       (deprecated depuis TS 5.0)

    "target": "ES2022",
    "module": "ESNext",
    "moduleResolution": "bundler"
  }
}

Regles imposees par verbatimModuleSyntax

// PROBLEME sans verbatimModuleSyntax
// TypeScript peut effacer silencieusement 'User' si c'est un type pur
import { User, fetchUser } from './user.service';
// Ambiguite : User est-il une valeur ou un type ?

// SOLUTION avec verbatimModuleSyntax : distinction explicite obligatoire

// Import d'une valeur (fonction, classe, constante) — conserve dans le JS produit
import { fetchUser } from './user.service';

// Import d'un type uniquement — efface entierement du JS compile
import type { User } from './user.service';

// Syntaxe mixte possible sur une meme ligne
import { fetchUser, type User } from './user.service';
// fetchUser est une valeur (conservee), User est un type (efface)

Impact sur Angular 17+

Angular recommande activement verbatimModuleSyntax depuis Angular 17. Les interfaces et types comme OnInit, Signal ou WritableSignal sont des types purs et doivent etre prefixes par type :

// Composant Angular 17+ avec verbatimModuleSyntax active
import { Component, signal } from '@angular/core';
// Component est un decorateur (valeur) : import normal
// signal() est une fonction (valeur) : import normal

import type { WritableSignal, OnInit } from '@angular/core';
// WritableSignal est une interface generique : import type obligatoire
// OnInit est une interface de lifecycle : import type obligatoire

@Component({
  selector: 'app-counter',
  standalone: true,
  template: `
    <button (click)="increment()">+</button>
    <p>Compteur : {{ count() }}</p>
  `,
})
export class CounterComponent implements OnInit {
  // signal() retourne un WritableSignal<number>, annote via import type
  count: WritableSignal<number> = signal(0);

  ngOnInit(): void {
    // Lifecycle hook appele apres l'initialisation du composant
    console.log('Compteur initialise a :', this.count());
  }

  increment(): void {
    // Mise a jour reactive du signal
    this.count.update(v => v + 1);
  }
}

Isolated declarations (TS 5.5)

TypeScript 5.5 introduit l'option isolatedDeclarations. Elle permet d'accelerer significativement la generation des fichiers .d.ts (declarations de types) en imposant que chaque symbole exporte ait un type annote explicitement, rendant possible la parallelisation de cette etape de build.

Le goulot d'etranglement sur les grands projets

Dans un monorepo ou une grande base TypeScript, la generation des .d.ts peut ralentir les builds. TypeScript doit analyser les dependances entre fichiers pour inferer les types des exports, ce qui impose un traitement sequentiel fichier par fichier.

Activer isolatedDeclarations dans tsconfig.json

// tsconfig.json — activer isolatedDeclarations pour les builds paralleles
{
  "compilerOptions": {
    "isolatedDeclarations": true,
    // Chaque fichier peut etre traite independamment pour generer son .d.ts
    // car aucune inference cross-fichiers n'est necessaire
    // Outils compatibles : oxc, SWC, esbuild, ts-blank-space

    "declaration": true,      // generation des fichiers .d.ts activee
    "declarationMap": true    // source maps pour .d.ts (debug, optionnel)
  }
}

Contraintes : types explicites sur les exports

Avec isolatedDeclarations, TypeScript exige que tous les symboles exportes aient un type annote explicitement. L'inference seule ne suffit plus pour les exports publics :

// ERREUR avec isolatedDeclarations : type de retour infere, pas explicite
export function getUser(id: number) {
  // Erreur TS : le type de retour doit etre annote pour isolatedDeclarations
  return fetch(`/api/users/${id}`).then(r => r.json());
}

// CORRECT : type de retour annote explicitement
export async function getUser(id: number): Promise<User> {
  // Le type Promise<User> est declare, aucune inference cross-fichiers requise
  const response = await fetch(`/api/users/${id}`);
  return response.json() as User;
}

// ERREUR : constante exportee sans type explicite
export const BASE_URL = 'https://api.example.com';
// Erreur TS : Type annotation required for exported const

// CORRECT : type explicite sur la constante exportee
export const BASE_URL: string = 'https://api.example.com';

// CORRECT : literal type explicite (plus precis)
export const BASE_URL: 'https://api.example.com' = 'https://api.example.com';

Gain de performance : le principe

Avec isolatedDeclarations, chaque fichier est autonome pour la generation de son .d.ts. Des outils comme oxc, SWC ou ts-blank-space peuvent traiter tous les fichiers en parallele, independamment les uns des autres.

Le mot-cle override (TS 4.3)

Le mot-cle override est disponible depuis TypeScript 4.3. Il permet de declarer explicitement qu'une methode de classe en surcharge une autre de la classe parente. Combine avec noImplicitOverride, il protege efficacement contre les bugs de refactoring invisibles.

Le probleme sans override

// Classe de base : composant Angular abstrait avec logique commune
class BaseFormComponent {
  // Methode de validation appelee avant la soumission du formulaire
  validate(): boolean {
    return true; // Validation par defaut : toujours valide
  }

  // Methode de reinitialisation
  resetForm(): void {
    console.log('Formulaire reinitialise');
  }
}

// Classe enfant SANS override — danger silencieux
class UserFormComponent extends BaseFormComponent {
  private email: string = '';
  private password: string = '';

  // Intention : surcharger validate() de la classe parente
  // Probleme : si BaseFormComponent renomme 'validate' en 'isValid',
  // ce code cree silencieusement une NOUVELLE methode orpheline
  // et la validation parente n'est plus surchargee !
  validate(): boolean {
    return this.email !== '' && this.password.length >= 8;
  }
}

La solution : noImplicitOverride et override

// tsconfig.json : detecter les surcharges implicites non declarees
{
  "compilerOptions": {
    "noImplicitOverride": true
    // TypeScript exigera le mot-cle 'override' sur toute methode surchargee
  }
}

// Classe de base inchangee
class BaseFormComponent {
  validate(): boolean {
    return true;
  }

  resetForm(): void {
    console.log('Formulaire reinitialise');
  }
}

// Classe enfant AVEC override : declaration d'intention explicite
class UserFormComponent extends BaseFormComponent {
  private email: string = '';
  private password: string = '';

  // 'override' signale la surcharge volontaire
  // TypeScript verifie que validate() existe dans la classe parente
  override validate(): boolean {
    return this.email !== '' && this.password.length >= 8;
  }

  // Exemple d'erreur detectee par TypeScript :
  // override nonExistent(): void {}
  // Erreur TS : This member cannot have an 'override' modifier because
  // it is not declared in the base class 'BaseFormComponent'
}

Application pratique Angular : lifecycle hooks herities

import { Component, OnInit, OnDestroy } from '@angular/core';

// Composant abstrait de base avec logique partagee (analytics, tracking...)
abstract class BasePageComponent implements OnInit, OnDestroy {
  // Initialisation commune : tracking de navigation, analytics
  ngOnInit(): void {
    console.log('Page initialisee — tracking analytics declenche');
  }

  // Nettoyage commun : subscriptions RxJS, timers...
  ngOnDestroy(): void {
    console.log('Page detruite — ressources liberees');
  }
}

// Composant page concret : surcharge explicite des hooks
@Component({
  selector: 'app-dashboard',
  standalone: true,
  template: `
    <h1>Dashboard</h1>
    <p>Bienvenue sur votre tableau de bord.</p>
  `,
})
export class DashboardComponent extends BasePageComponent {
  // 'override' declare la surcharge de ngOnInit de la classe parente
  // Si BasePageComponent supprime ngOnInit, TypeScript signalera l'erreur ici
  override ngOnInit(): void {
    super.ngOnInit();           // Appel de la logique parente (analytics)
    this.loadDashboardData();   // Logique specifique au dashboard
  }

  private loadDashboardData(): void {
    // Chargement des donnees du tableau de bord depuis l'API
    console.log('Chargement des donnees dashboard...');
  }

  // ngOnDestroy n'est pas surchargee : la logique parente s'applique directement
}

Tableau recapitulatif des nouveautes

Voici un tableau de synthese des fonctionnalites couvertes, avec leur version d'introduction, leur utilite principale et leur pertinence dans un contexte Angular.

Conclusion

TypeScript 5.x apporte des outils concrets qui ameliorent la qualite du code, la vitesse de build et la robustesse des refactorings. L'operateur satisfies, les const type parameters, les declarations using, verbatimModuleSyntax, isolatedDeclarations et le mot-cle override repondent chacun a un probleme reel rencontre en production.

Ces fonctionnalites ne necessitent pas de reecrire votre projet. Adoptez-les progressivement : commencez par override avec noImplicitOverride et verbatimModuleSyntax qui apportent une valeur immediate avec un effort minimal, puis explorez satisfies et les const type parameters pour vos nouveaux developpements.