Maîtriser les Types Avancés et le Système de Module TypeScript

Les Génériques Conditionnels et l'Inférence de Types Avancée

Les génériques conditionnels représentent l'une des fonctionnalités les plus puissantes du système de types TypeScript. Il s'agit d'une syntaxe qui permet de créer des types qui se comportent différemment selon certaines conditions, offrant une flexibilité extraordinaire pour construire des abstractions de haut niveau.

Définition: Un générique conditionnel est un type qui évalue une condition sur un autre type et retourne l'un de deux types possibles en fonction du résultat. La syntaxe générale est T extends U ? X : Y, où T est testé contre U, et si la condition est vraie, le type résultant est X, sinon Y.

Explication: Ces génériques conditionnels permettent de créer des mappages de types sophistiqués qui réagissent dynamiquement à la structure des types passés en paramètre. C'est particulièrement utile pour implémenter des transformations de types qui dépendent de la forme du type d'entrée. L'inférence de types fonctionne en conjonction avec les génériques conditionnels via le mot-clé infer, qui capture des parties de types complexes pour les réutiliser.

Bloc code:

// Exemple basique de générique conditionnel
type IsString<T> = T extends string ? true : false;
type A = IsString<"hello">; // true
type B = IsString<42>; // false

// Utilisation d'infer pour extraire des types
type ReturnType<T> = T extends (...args: any[]) => infer R ? R : never;
type FuncReturnType = ReturnType<(x: number) => string>; // string

// Exemple avancé : Flatten récursif
type Flatten<T> = T extends Array<infer U> ? Flatten<U> : T;
type NestedArray = Flatten<[[[number]]]>; // number

// Generique conditionnel distribué
type Unwrap<T> = T extends Promise<infer U> ? U : T;
type A = Unwrap<Promise<string>>; // string
type B = Unwrap<Promise<Promise<number>>>; // Promise<number>
type C = Unwrap<boolean>; // boolean

// Cas complexe : extraire les clés optionnelles
type OptionalPropertyNames<T> = {
  [K in keyof T]-?: {} extends Pick<T, K> ? K : never;
}[keyof T];

interface User {
  id: number;
  name: string;
  email?: string;
  phone?: string;
}

type OptionalKeys = OptionalPropertyNames<User>; // "email" | "phone"

Tableau comparatif:

Astuce: Utilisez T extends U ? true : false plutôt que simplement T extends U pour forcer l'évaluation du type et éviter les pièges de la distributivité. Aussi, mémorisez les patterns d'inférence courants : infer R pour return types, infer Args extends any[] pour les paramètres, et infer K extends string pour les clés.

Attention: ⚠️ Les génériques conditionnels avec unions se distribuent automatiquement. T extends string ? A : B appliquera la condition à chaque élément si T est une union. Utilisez [T] extends [string] pour désactiver cette distributivité. Aussi, les erreurs de types récursifs peuvent causer des timeouts du compilateur TypeScript—limitez toujours la profondeur de récursion.

Variance des Types et Contraintes Bivariance

La variance est un concept fondamental en théorie des types qui détermine comment les types se comportent dans les relations d'héritage et de substitution. TypeScript implémente une variance complexe et souvent contre-intuitive qui peut causer des bugs subtils en production.

Définition: La variance décrit les règles selon lesquelles un type générique peut être assigné à un autre. La covariance signifie que si A <: B, alors Box<A> <: Box<B>. La contravariance signifie l'inverse : si A <: B, alors Box<B> <: Box<A>. L'invariance signifie qu'aucune de ces relations ne s'applique.

Explication: TypeScript utilise la bivariance pour les paramètres de fonction, ce qui est techniquement incorrect du point de vue de la théorie des types mais pratique en réalité. Cependant, cette flexibilité introduit des cas d'erreur non détectés. Les positions différentes dans une déclaration de type ont des variances différentes : les propriétés en lecture sont covariantes, celles en écriture sont contravariantes. Les paramètres de fonction sont bivariance, ce qui permet l'assignation flexibile mais crée des failles de sécurité de type.

Bloc code:

// Covariance en positions de lecture
interface Animal { name: string; }
interface Dog extends Animal { breed: string; }

const dogs: Dog[] = [];
const animals: Animal[] = dogs; // ✓ Covariant - Dog[] assignable à Animal[]

// Contravariance en positions d'écriture
function feedAnimal(animal: Animal) { console.log("feeding"); }
function feedDog(dog: Dog) { console.log("feeding dog"); }

const animalFeeder: (animal: Animal) => void = feedDog; // ⚠️ Bivariance - Accepté mais dangereux
const dogFeeder: (dog: Dog) => void = feedAnimal; // ✓ Contravarant correct

// Cas problématique : bivariance sans contrôle
class EventEmitter<T> {
  listeners: ((event: T) => void)[] = [];
  
  addListener(callback: (event: T) => void) {
    this.listeners.push(callback);
  }
  
  emit(event: T) {
    this.listeners.forEach(cb => cb(event));
  }
}

const animalEvents = new EventEmitter<Animal>();
const dogListener = (dog: Dog) => console.log(dog.breed); // Accident!
animalEvents.addListener(dogListener); // Accepté par bivariance
animalEvents.emit({ name: "Cat" }); // Runtime error!

// Solution : utiliser des contraintes génériques
class StrictEventEmitter<T> {
  listeners: Array<(event: T) => void> = [];
  
  addListener<E extends T>(callback: (event: E) => void) {
    // Cette approche force la contravariance correcte
    this.listeners.push(callback as (event: T) => void);
  }
  
  emit(event: T) {
    this.listeners.forEach(cb => cb(event));
  }
}

// Désactiver la bivariance avec useUnknownInCatchVariables
try {
  // ...
} catch (error) { // error: unknown (plus sûr que any)
  if (error instanceof Error) {
    console.log(error.message);
  }
}

Tableau comparatif:

Astuce: Activez strictFunctionTypes: true et strictPropertyInitialization: true dans tsconfig.json pour éliminer la bivariance et renforcer les règles de variance. Déclarez les paramètres génériques en tant que readonly quand possible pour forcer la covariance.

Attention: ⚠️ La bivariance des paramètres de fonction est une faille majeure de sécurité de type en TypeScript. Des objets de types non conformes peuvent être passés à la compilation sans erreur. Testez toujours avec --strict activé. Les modifications de variance lors d'une mise à jour de TypeScript peuvent casser du code apparemment valide.

Mapped Types, Template Literal Types et Manipulations Structurelles

Les mapped types et template literal types permettent de créer des transformations structurelles sophistiquées sur des types existants, offrant une abstraction puissante pour générer automatiquement des variantes de types.

Définition: Un mapped type transforme chaque propriété d'un type source en une nouvelle propriété selon une règle définie. La syntaxe { [K in keyof T]: ... } itère sur toutes les clés de T. Les template literal types combinent les littéraux de chaîne avec des unions pour créer de nouveaux types de chaîne basés sur les propriétés d'autres types.

Explication: Les mapped types sont essentiels pour maintenir la synchronisation entre les types. Quand vous avez plusieurs variantes d'un type (readonly, nullable, optional), les mapped types évitent la duplication. Les template literal types permettent de générer des noms de propriétés ou de fonctions basés sur des patterns. Ensemble, ils créent un système de transformation de type hautement expressif qui réduit les erreurs et améliore la maintenabilité. Cependant, ils peuvent impacter les performances du compilateur s'ils sont utilisés de manière inefficace.

Bloc code:

// Mapped type basique
type Readonly<T> = {
  readonly [K in keyof T]: T[K];
};

// Mapped type avec conditional
type Getters<T> = {
  [K in keyof T as `get${Capitalize<string & K>}`]: () => T[K];
};

interface Person {
  name: string;
  age: number;
}

type PersonGetters = Getters<Person>;
// {
//   getName: () => string;
//   getAge: () => number;
// }

// Template literal types
type EventNames = "click" | "hover" | "change";
type EventHandlers<E extends string> = `on${Capitalize<E>}`;
type Handler = EventHandlers<EventNames>; // "onClick" | "onHover" | "onChange"

// Combinaison avancée : générateur de types Builder
type BuilderMethods<T> = {
  [K in keyof T as `set${Capitalize<string & K>}`]: (value: T[K]) => Builder<T>;
};

class Builder<T> implements BuilderMethods<T> {
  private state: Partial<T> = {};
  
  [key: string]: (value: any) => Builder<T>;
  
  constructor() {
    const keys = Object.keys(this.state) as (keyof T)[];
    keys.forEach(key => {
      const methodName = `set${String(key).charAt(0).toUpperCase()}${String(key).slice(1)}`;
      (this as any)[methodName] = (value: T[typeof key]) => {
        this.state[key] = value;
        return this;
      };
    });
  }
  
  build(): T {
    return this.state as T;
  }
}

// Mapped type avec filtrage
type ReadonlyProperties<T> = {
  [K in keyof T as T[K] extends (...args: any[]) => any ? never : K]: T[K];
};

interface Mixed {
  name: string;
  getValue(): number;
  age: number;
}

type MixedReadonly = ReadonlyProperties<Mixed>;
// { name: string; age: number; } - getValue est exclu

// Template literal avancé pour les paths
type Path<T> = T extends object ? {
  [K in keyof T]: K extends string | number
    ? `${K}` | `${K}.${Path<T[K]>}`
    : never;
}[keyof T] : never;

interface Config {
  server: { host: string; port: number; };
  db: { username: string; };
}

type ConfigPaths = Path<Config>;
// "server" | "server.host" | "server.port" | "db" | "db.username"

Tableau comparatif:

Astuce: Utilisez as const avec les unions littérales dans les mapped types pour améliorer l'inférence. Créez des utilitaires génériques réutilisables : type Keys<T> = keyof T & string. Pour les performances, mettez en cache les résultats de mapped types complexes en créant des aliases intermédiaires plutôt que d'imbriquer directement.

Attention: ⚠️ Les mapped types récursifs profonds peuvent faire ralentir le compilateur TypeScript jusqu'au timeout. Limitez la profondeur ou utilisez des indices numériques pour déboguer (: au lieu de in). Les template literal types avec unions exponentielles créent des types énormes qui ralentissent l'IDE. Évitez les combinaisons inutiles de mapped types imbriqués et testez avec tsc --noEmit --explainFiles.

Système de Module, Tree-Shaking et Optimisation des Exports

Le système de module TypeScript interagit étroitement avec les bundlers modernes pour produire du code final optimisé. Comprendre ces interactions est crucial pour déboguer les problèmes de performance et de tree-shaking.

Définition: Le système de module TypeScript convertit les imports et exports ES6 (ou CommonJS) en code JavaScript exécutable. Le tree-shaking est une technique de bundling qui élimine le code mort des dépendances non utilisées. L'optimisation des exports consiste à structurer les modules pour maximiser l'efficacité du tree-shaking et minimiser la taille du bundle final.

Explication: TypeScript supporte plusieurs formats de module (ES6, CommonJS, AMD, UMD). Le choix du format affecte directement la capacité des bundlers à éliminer le code mort. Les exports nommés (named exports) permettent un tree-shaking précis, tandis que les exports par défaut (default exports) et les exports dynamiques inhibent souvent le tree-shaking. Les re-exports et les exports avec des effets secondaires compliquent l'analyse statique. Les fichiers package.json avec les champs exports, main, module et types contrôlent la résolution des modules et impactent directement quels fichiers sont chargés et potentiellement tree-shaken.

Bloc code:

// ❌ Mauvais : default export empêche le tree-shaking
export default {
  utils: {
    add: (a: number, b: number) => a + b,
    multiply: (a: number, b: number) => a * b,
    expensiveOperation: () => { /* heavy computation */ }
  }
};

import * as math from "./math"; // Tout est inclus dans le bundle
const result = math.utils.add(1, 2);

// ✓ Bon : named exports permettent le tree-shaking
export const add = (a: number, b: number) => a + b;
export const multiply = (a: number, b: number) => a * b;
export const expensiveOperation = () => { /* heavy computation */ };

import { add } from "./math"; // Seul 'add' est inclus dans le bundle
const result = add(1, 2);

// Configuration optimale dans package.json
{
  "name": "my-library",
  "version": "1.0.0",
  "type": "module", // Défaut ES6
  "exports": {
    ".": {
      "types": "./dist/index.d.ts",
      "import": "./dist/index.mjs",
      "require": "./dist/index.cjs"
    },
    "./utils": {
      "types": "./dist/utils/index.d.ts",
      "import": "./dist/utils/index.mjs",
      "require": "./dist/utils/index.cjs"
    }
  },
  "main": "./dist/index.cjs",
  "module": "./dist/index.mjs",
  "types": "./dist/index.d.ts",
  "sideEffects": false // Crucial pour le tree-shaking!
}

// Side effects à déclarer explicitement
{
  "sideEffects": [
    "./dist/polyfills.js",
    "*.css"
  ]
}

// ⚠️ Problème : re-export * crée des dépendances implicites
// lib/index.ts
export * from "./math";
export * from "./strings";
export * from "./arrays";

// L'import de lib inclut TOUS les modules, même non utilisés
import { add } from "./lib";

// ✓ Solution : re-exports sélectifs
export { add, multiply } from "./math";
export { toUpperCase } from "./strings";
// Seul 'add' et 'multiply' et 'toUpperCase' sont disponibles

// Analyse de dépendances avec tsconfig
{
  "compilerOptions": {
    "module": "esnext", // Important : préserve ES6 imports/exports
    "target": "es2020",
    "declaration": true,
    "declarationMap": true
  }
}

// Utiliser les barrel exports avec caution
// ✗ Re-export massivement
export * from "./components/Button";
export * from "./components/Card";
export * from "./components/Modal";

// ✓ Re-export minimalement
export { Button } from "./components/Button";
export type { ButtonProps } from "./components/Button";

// Vérifier le tree-shaking avec un bundler
// webpack.config.js
module.exports = {
  mode: 'production',
  optimization: {
    usedExports: true,
    sideEffects: false
  }
};

Tableau comparatif:

Astuce: Utilisez "sideEffects": false dans package.json seulement si votre code n'a vraiment aucun effet secondaire (pas de polyfills, pas de mutations globales). Inspectez le bundle réel avec webpack-bundle-analyzer ou source-map-explorer pour vérifier que le tree-shaking fonctionne. Divisez les modules volumineux en sous-modules plus petits pour améliorer la granularité du tree-shaking.

Attention: ⚠️ Les imports dynamiques (import()) et les re-exports (export *) inhibent le tree-shaking. Les CommonJS et les exports nommés par variable (export const x = ...) au lieu de export { x } peuvent empêcher le tree-shaking selon le bundler. Les compilateurs TypeScript modernes transpilent les modules différemment selon module - utilisez esnext pour les bundlers modernes et es2020 pour les targets. Des dépendances déclarées mais non utilisées dans les imports restent dans le bundle : auditer régulièrement avec npm ls ou des outils dédiés.

Débogage Avancé, Performance du Compilateur et Profiling de Types

Déboguer des problèmes TypeScript avancés nécessite une compréhension profonde de comment le compilateur travaille en interne, et des outils spécialisés pour identifier les goulots d'étranglement et les erreurs de types subtiles.

Définition: Le profiling de types consiste à mesurer la performance du compilateur TypeScript, notamment le temps passé à inférer et à vérifier les types. Le débogage avancé implique des techniques pour inspecter les types inférés, tracer l'origine des erreurs de types et identifier les génériques problématiques. Les outils de débogage vont des flags du compilateur aux scripts personnalisés qui analysent les fichiers .d.ts générés.

Explication: Le compilateur TypeScript peut ralentir considérablement sur de larges codebases en raison d'une inférence de type excessivement complexe, de génériques mal optimisés ou de dépendances circulaires. Les causes courantes incluent les génériques récursifs profonds, les mapped types imbriqués, les unions exponentielles et l'inférence agressive à partir de code dynamique. Déboguer ces problèmes exige d'isoler les sources de ralentissement, souvent invisibles sans outils appropriés. TypeScript fournit des flags de débogage et des modes d'analyse qui exposent la structure interne des types et les décisions d'inférence.

Bloc code:

// 1. Utiliser --diagnostics et --extendedDiagnostics
// Commande : tsc --diagnostics --extendedDiagnostics > stats.txt

// 2. Trouver les types problématiques avec des heuristiques
// Créer un fichier de test pour isoler les performances
type ExpensiveUnion = 
  | { type: 'a'; value: string }
  | { type: 'b'; value: number }
  | { type: 'c'; value: boolean }
  | { type: 'd'; value: null }
  | { type: 'e'; value: undefined };

// Discriminate union avec performance
type Discriminate<T extends { type: string }> = T extends any
  ? { [K in T['type']]: Extract<T, { type: K }> }
  : never;

type Result = Discriminate<ExpensiveUnion>;
// Potentiellement lent pour les grandes unions

// 3. Inspecter les types inférés
const debugType: ReturnType<typeof someFunction> = null!; // Hover sur debugType

// 4. Utiliser des contraintes pour accélérer l'inférence
function processData<T extends Record<string, any>>(data: T): T {
  return data;
}

// ✗ Lent : pas de contrainte, inférence large
const result1 = processData({ a: 1, b: "x", c: [] });

// ✓ Rapide : contrainte délimite l'espace de recherche
const result2 = processData<{ a: number; b: string }>(
  { a: 1, b: "x" }
);

// 5. Isoler et mesurer des parties spécifiques
// tsconfig.json avec isolatedModules pour paralléliser
{
  "compilerOptions": {
    "isolatedModules": true,
    "skipLibCheck": true,
    "incremental": true
  }
}

// 6. Profiler une fonction spécifique
import type { performance } from 'perf_hooks';

function profileType<T>(label: string, fn: () => T): T {
  const start = Date.now();
  const result = fn();
  const elapsed = Date.now() - start;
  console.log(`[${label}] ${elapsed}ms`);
  return result;
}

type SlowType = profileType<any>("SlowMapping", () => {
  // Type complexe ici
  type Result = Readonly<Record<string, { readonly [K in string]: any }>>;
  return null as any;
});

// 7. Utiliser les flags de diagnostic
// tsc --noEmit --pretty false --listFiles > compilation.log
// grep "error TS" compilation.log | sort | uniq -c | sort -rn

// 8. Script de détection de problèmes de performance
const fs = require('fs');
const path = require('path');

function analyzeTypeComplexity(typeName: string): number {
  // Exemple simplifié : compter les caractères et la profondeur
  const depth = (typeName.match(/[<{[]/g) || []).length;
  const unionSize = (typeName.match(/\|/g) || []).length;
  return depth * unionSize;
}

// 9. Debugging avec never for caught errors
function assertNever(x: never): never {
  throw new Error(`Unexpected value: ${x}`);
}

type MyUnion = 'a' | 'b' | 'c';
function handleUnion(x: MyUnion) {
  if (x === 'a') return 'case a';
  if (x === 'b') return 'case b';
  // L'oubli de 'c' génère une erreur de type
  return assertNever(x); // TS2345 si 'c' non géré
}

// 10. Cache et mémoïsation pour les génériques fréquents
type CachedGeneric<T> = T extends (...args: any[]) => infer R
  ? R extends (...args: any[]) => any ? ReturnType<R> : R
  : T;

// Éviter le recalcul répété
type ExpensiveTypeTransform<T> = /* complexe */
  T extends string ? `string_${typeof T}`
  : T extends number ? `number_${typeof T}`
  : T extends boolean ? `bool_${typeof T}`
  : never;

// Alias pour réduire le recalcul
type StringTransform = ExpensiveTypeTransform<string>; // Mémoïsé

Tableau comparatif:

Astuce: Activez skipLibCheck: true dans tsconfig.json pour gagner 30-40% de temps de compilation sans sacrifier la sécurité du type (les lib .d.ts sont vérifiées avant publication). Utilisez incremental: true et tsBuildInfoFile pour exploiter le cache entre compilations. Pour déboguer interactivement, survolez les variables dans votre IDE avec Ctrl+Shift+X (Reveal Type) pour inspecter les types inférés.

Attention: ⚠️ Les generiques récursifs sans limite de profondeur causent des crash du compilateur. Établissez toujours des profondeurs maximales : type Depth = [any, any, any] (limite 3 niveaux). Les performance regressions peuvent survenir après une mise à jour TypeScript mineure - versionnez strictement et testez les temps de compilation. Certains IDE (VSCode) cachent les vraies erreurs de performance derrière des interfaces d'inférence lentes : testez toujours en ligne de commande pure avec tsc. Ne jamais utiliser any pour "ignorer" les problèmes de performance de types - cela masque les vrais problèmes jusqu'au runtime.