frontend / typescript

Pourquoi TypeScript et configuration (tsconfig)

Leçon 11 exercice

Explication

Un peu d'histoire

TypeScript est créé par Microsoft sous la direction d'Anders Hejlsberg — aussi créateur de Turbo Pascal et de C# — et rendu public en octobre 2012. L'idée de départ est simple : à mesure que les applications JavaScript grossissaient (des milliers, voire des millions de lignes), l'absence totale de vérification de types rendait le code de plus en plus difficile à maintenir et source de bugs qu'on ne découvrait qu'à l'exécution, parfois en production.

TypeScript est conçu comme un sur-ensemble de JavaScript : tout code JavaScript valide est aussi du code TypeScript valide. Il ajoute simplement, par-dessus, un système de typage optionnel qui est vérifié avant l'exécution puis "compilé" (transpilé) vers du JavaScript classique.

Pourquoi apprendre TypeScript aujourd'hui

TypeScript permet de détecter énormément d'erreurs avant même de lancer le code, simplement en vérifiant que les types utilisés sont cohérents. Il améliore aussi considérablement l'autocomplétion et la navigation dans un projet, ce qui devient précieux dès qu'une équipe grandit. Il est devenu un standard de facto dans l'industrie : Angular l'impose, la grande majorité des nouveaux projets React professionnels l'utilisent, et sa maîtrise est aujourd'hui une compétence très recherchée pour tout poste de développeur frontend ou full-stack JavaScript.

Ce que vous allez apprendre

Expliquer ce que TypeScript ajoute concrètement à JavaScript
Installer TypeScript et générer un tsconfig.json avec tsc --init
Comprendre le rôle central de l'option strict et pourquoi la désactiver est une fausse économie
Utiliser tsc --noEmit pour vérifier les types dans une CI sans dupliquer le build
Distinguer ce que tsc vérifie (les types) de ce qu'il ne remplace pas (les tests)

Dans quel contexte ?

Une équipe reprend un projet JavaScript de 50 000 lignes où une fonction calculerRemise(prix, code) est appelée à plus de 40 endroits différents dans le code. Un développeur doit ajouter un troisième paramètre obligatoire, mais sans typage, impossible de savoir avec certitude combien d'appels existants vont casser sans les relire un par un. Avec TypeScript et strict: true, le compilateur signalerait instantanément chaque appel non mis à jour avec une erreur précise (fichier, ligne, paramètre manquant), avant même de lancer le moindre test.

Prérequis

Une bonne connaissance de JavaScript (variables, fonctions, objets) est nécessaire pour aborder ce cours : TypeScript est un sur-ensemble de JavaScript, pas un langage à part qui s'apprendrait indépendamment.

Le problème que résout TypeScript

JavaScript ne vérifie rien avant l'exécution : une erreur de type ne se révèle que lorsque le code tourne réellement, parfois chez l'utilisateur final. TypeScript ajoute une couche de vérification qui s'exécute avant même de lancer le programme, au moment où vous écrivez le code.

Imaginez une équipe de relecteurs qui vérifie chaque clause d'un contrat avant sa signature : c'est le rôle du compilateur TypeScript (tsc). Il lit votre code, vérifie que les types sont cohérents (on n'additionne pas un texte et un nombre par erreur, on n'appelle pas une méthode qui n'existe pas), puis transforme ("transpile") ce code en JavaScript ordinaire que n'importe quel navigateur ou Node.js peut exécuter.

Le fichier de configuration

Le fichier tsconfig.json est la carte d'identité du projet : il indique où sont les fichiers sources, où écrire le résultat compilé, quelle version de JavaScript cibler, et surtout quel niveau de rigueur appliquer via l'option strict. Démarrer un projet TypeScript sans activer strict revient à acheter un correcteur orthographique puis le désactiver : on perd l'essentiel de sa valeur.

Commande	Effet
`tsc --init`	Génère un `tsconfig.json` commenté
`tsc`	Compile tout le projet selon `tsconfig.json`
`tsc --watch`	Recompile automatiquement à chaque sauvegarde
`tsc --noEmit`	Vérifie les types sans écrire de JS (idéal en CI)

Pièges fréquents

Désactiver strict pour aller plus vite : c'est une fausse économie, les bugs reviennent plus tard, plus coûteux à corriger.
Confondre compilation et exécution : tsc ne fait que vérifier et traduire, il ne remplace pas les tests.

Piège fréquent

strict: false (ou l'absence de cette option) laisse passer silencieusement des erreurs comme null assigné à une variable censée être un string. Activez toujours strict: true dès la création du projet : l'activer après coup, sur un gros projet, demande bien plus d'efforts.

Cette leçon pose les fondations : toutes les suivantes supposent un projet déjà correctement configuré.

Commandes & code

Pourquoi TypeScript ?

TypeScript ajoute un système de types statique à JavaScript et détecte les erreurs à la compilation plutôt qu'en production.

// JavaScript : l'erreur explose au runtime, chez l'utilisateur
function total(prix, quantite) {
  return prix * quantite;
}
console.log(total("12", 3)); // "121212" au lieu de 36 — aucune alerte

// TypeScript : l'erreur est détectée avant même d'exécuter le code
function totalTs(prix: number, quantite: number): number {
  return prix * quantite;
}
totalTs("12", 3);
// Error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.

npm install -D typescript
npx tsc --init          # génère un tsconfig.json commenté

// tsconfig.json minimal, prêt pour un vrai projet
{
  "compilerOptions": {
    "target": "ES2022",                 // JS généré, compatible runtimes récents
    "lib": ["ES2022", "DOM"],           // API disponibles (Promise, fetch, document...)
    "module": "ESNext",                 // système de modules en sortie
    "moduleResolution": "Bundler",      // résolution façon Vite/webpack/esbuild
    "outDir": "./dist",
    "rootDir": "./src",
    "strict": true,                     // active TOUTES les vérifications strictes
    "esModuleInterop": true,            // import propre des paquets CommonJS
    "skipLibCheck": true,               // ignore les .d.ts des dépendances (perf)
    "forceConsistentCasingInFileNames": true,
    "resolveJsonModule": true,
    "isolatedModules": true             // chaque fichier doit être transpilable seul
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules", "dist"]
}

npx tsc               # compile tout le projet selon tsconfig.json
npx tsc --watch        # recompile à chaque sauvegarde
npx tsc --noEmit       # vérifie les types sans écrire de JS (utile en CI)

Résumé

TypeScript = JavaScript + types statiques, transpilé en JS pur.
tsc --init génère la config de base ; strict: true doit rester activé.
--noEmit sert de garde-fou de types dans une CI, sans dupliquer le build.
moduleResolution: "Bundler" colle au comportement des bundlers modernes.

Exercices pratiques

1 disponible

Mission : durcir la configuration d'un projet hérité

Objectif : Auditer un tsconfig.json insuffisamment strict et le corriger pour révéler les bugs de typage qu'il laisse actuellement passer.

Contexte

Tu reprends un projet TypeScript existant dont le tsconfig.json ne contient ni strict, ni de vérification de types dans la CI. Une fonction totalTs(prix, quantite) a été appelée quelque part avec une chaîne de caractères à la place d'un nombre, et personne ne l'a remarqué avant la mise en production. Ta mission : comprendre pourquoi ce silence est dangereux, puis corriger la configuration pour qu'il devienne impossible.

Résoudre l’exercice →