5.1Node.js avec TypeScript
L'essentiel en 30 secondes
- TS = JS + types : sur-ensemble de JavaScript — tout JS valide est du TS valide, on ajoute le typage statique par-dessus.
- Erreurs avant l'exécution : le compilateur vérifie les types et attrape toute une catégorie de bugs à la compilation, pas en production.
- Outillage et équipe : autocomplétion précise, refactoring sûr, code qui se documente — décisif sur les projets sérieux.
Mini-cas filé — Salim type son API à Alger
Salim, développeur junior à Alger, maintient une petite API de suivi des commandes : un champ « quantité » arrive parfois en texte, un nom de propriété mal tapé fait planter une route en production. Il introduit TypeScript progressivement : il annote ses fonctions, définit une interface pour ses données, laisse le compilateur attraper les incohérences avant l'exécution. Cette section raconte sa bascule — et le fil continue en 5.2, 5.3 et 5.4.
Ce même cas revient dans le cours, le schéma, le script et le défi 48h — et continue en 5.2, 5.3 et 5.4.
1. Un sur-ensemble typé
TypeScript est un sur-ensemble de JavaScript qui ajoute le typage statique : tout JavaScript valide est du TypeScript valide, les types se déclarent par-dessus (let age: number, function f(nom: string): string). TypeScript vérifie la cohérence AVANT l'exécution (à la compilation) et attrape des erreurs que JavaScript, au typage dynamique, ne révélerait qu'au runtime : type incompatible, propriété inexistante, argument manquant. Salim y retrouve tout son JavaScript — avec un filet de sécurité en plus.
La règle d'ordre : JavaScript d'abord, types par-dessus. On ne type bien que ce qu'on comprend : les types décrivent des structures et des fonctions JavaScript déjà maîtrisées. Salim solidifie son JS (niveau 1), puis annote.
2. Compilation et bénéfices
TypeScript ne s'exécute pas directement : il se compile en JavaScript ordinaire (fichiers .ts → .js via tsc, configuré par tsconfig.json ; ts-node l'exécute en développement). Bénéfices : détection d'erreurs à la compilation, autocomplétion et outillage supérieurs dans l'éditeur, documentation implicite (les types décrivent le code), robustesse et maintenabilité sur les gros projets et en équipe. Salim refactorise sans peur : le compilateur signale ce qui casse ailleurs.
Quasi standard en Node professionnel, excellent avec les outils modernes typés (Prisma, Zod). Le coût existe — apprentissage du système de types, étape de compilation, un peu de verbosité réduite par l'inférence — mais sur une application sérieuse, le calcul est largement favorable.
3. Progressif, pas tout ou rien
TypeScript s'apprend progressivement : typage léger au début (annotations simples), interfaces et types avancés ensuite. L'inférence devine souvent les types sans qu'on les écrive — pas besoin de tout annoter. Pour un tout petit script jetable, JavaScript pur suffit ; pour une application qui grandit, dure ou se fait en équipe, TypeScript vaut l'effort. Salim commence par typer ses structures de données (un type Commande) et ses retours de fonctions.
À éviter : apprendre TypeScript sans base JavaScript solide (deux apprentissages mélangés), ou forcer le typage strict partout dès le premier jour. Le bon rythme : annoter l'essentiel, laisser l'inférence faire le reste, durcir ensuite.
🔎 Exemple concret — Salim attrape un bug avant la production
Erreur de type détectée à la compilation.
interface Commande { article: string; quantite: number; }
function total(c: Commande): number {
return c.quantite * 2;
}
total({ article: 'câble', quantite: '3' });
// ❌ TS : 'quantite' doit être number — attrapé AVANT l'exécutionLecture : en JavaScript pur, l'erreur n'apparaît qu'au runtime — voire en production.
Leçon : une catégorie entière de bugs éliminée pendant que l'on code.
Vocabulaire de la section
- TypeScript
- Sur-ensemble de JavaScript ajoutant le typage statique ; se compile en JS ordinaire.
Exemple simple : Salim type son API de commandes à Alger sans réécrire sa logique.
Ce que ce n'est pas : un langage différent qu'il faudrait apprendre à part.
Réflexe : mon JS tourne déjà ? j'ajoute les types par-dessus.
- Typage statique
- Types déclarés et vérifiés avant l'exécution, à la compilation.
Exemple simple : Une quantité en texte est signalée avant tout déploiement.
Ce que ce n'est pas : une vérification qui n'aurait lieu qu'au runtime.
Réflexe : cette erreur serait-elle visible avant la production ?
- Compilation (tsc)
- Le compilateur vérifie les types puis transforme les .ts en .js.
Exemple simple : Salim lance tsc : zéro erreur, le .js est généré.
Ce que ce n'est pas : une exécution directe du .ts par Node sans étape.
Réflexe : tsconfig.json réglé avant de compiler ?
- Inférence
- TypeScript devine souvent les types sans annotation explicite.
Exemple simple : Salim n'annote pas chaque variable locale, TS les déduit.
Ce que ce n'est pas : l'obligation de tout annoter partout.
Réflexe : ce type a-t-il besoin d'être écrit, ou est-il deviné ?
- Adoption progressive
- Typage léger d'abord, types avancés ensuite, en réutilisant son JS.
Exemple simple : Salim type ses structures puis durcit au fil des semaines.
Ce que ce n'est pas : tout typer en strict dès le premier jour.
Réflexe : quel est le plus petit typage utile cette semaine ?
En pratique — Typer son back-end avec TypeScript
- Configurez un projet TypeScript (tsconfig.json) et exécutez du .ts en développement (ts-node ou support natif).
- Annotez des types : variables (`let age: number`), paramètres et retours de fonctions (`function f(x: string): number`).
- Constatez la détection d'erreurs à la compilation : passez un mauvais type, accédez à une propriété inexistante — TypeScript vous alerte AVANT l'exécution.
- Appréciez l'autocomplétion et l'outillage dans VS Code ; introduisez des interfaces/types pour vos structures de données (ex. un type Commande).
Script prêt à dire — proposer TypeScript à l'équipe
« Sur notre API à Alger, je propose d'introduire TypeScript progressivement : on garde notre JavaScript, on annote nos structures et nos fonctions, et le compilateur attrapera les erreurs de types avant la production. On commence léger — interfaces et signatures — et on durcit ensuite. Objectif : moins de plantages au runtime et un code plus lisible en équipe. »
À dire en réunion d'équipe pour faire adopter le typage par étapes, sans promettre une migration totale immédiate.
Modèle copier-coller — base tsconfig.json
TS — BASE PROJET
{
"compilerOptions": {
"target": "ES2022",
"module": "commonjs",
"outDir": "dist",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true
},
"include": ["src/**/*"]
}
COMMANDES : npx tsc --init (générer) · npx tsc --noEmit (vérifier) · npx tsc (compiler vers dist)Solo / petit budget
Salim seul : un tsconfig de base + annotations sur les structures critiques suffit — vérifier avec tsc avant chaque déploiement.
TPE / équipe réduite
Typer les signatures partagées (API, modèles) en priorité : c'est là que les erreurs d'intégration naissent.
PME à Alger
Salim cale le passage en TypeScript avec l'équipe à Alger : d'abord les nouveaux fichiers en .ts, migration du reste au fil de l'eau.
Équipe qui démarre
Binôme : l'un écrit le JS, l'autre ajoute les interfaces ; revue croisée des types avant chaque fusion.
✓ Bonnes pratiques
- Apprendre TS progressivement (typage de base, puis interfaces et génériques).
- Réutiliser votre JavaScript (TS = JS + types).
- Adopter TypeScript sur les projets sérieux (robustesse, outillage, équipe).
✗ Pièges fréquents
- Apprendre TS sans base JavaScript solide (on ne type bien que ce qu'on comprend).
- Forcer TypeScript sur un tout petit script jetable (excessif).
- Ignorer l'inférence et sur-annoter ce que TS devine déjà.
Points clés à retenir
- TypeScript = sur-ensemble de JavaScript ajoutant le TYPAGE STATIQUE (tout JS valide est du TS valide) ; se COMPILE en JS ordinaire.
- Typage STATIQUE (TS) : types vérifiés AVANT l'exécution → attrape une catégorie d'erreurs tôt (vs JS dynamique, bugs au runtime).
- Bénéfices : détection d'erreurs à la compilation, AUTOCOMPLÉTION/outillage supérieurs, documentation implicite, robustesse et maintenabilité.
- Quasi standard en Node professionnel ; excellent avec les outils modernes (Prisma, Zod typés). S'apprend progressivement ; la maîtrise de JS est réutilisée.
Défi 48h — appliquez demain
Prenez 1 fonction de votre API et écrivez son interface + sa signature typée : le compilateur détecte-t-il une incohérence que Salim aurait manquée ?
- Je peux expliquer TS = JS + types en une phrase.
- Ma fonction est typée (interface + signature) et vérifiée.
- Je sais quand JS pur suffit et quand TS s'impose.
Questions fréquentes
TypeScript vaut-il l'effort supplémentaire par rapport à JavaScript ?
Pour la plupart des projets sérieux, oui — l'adoption massive de l'industrie le confirme. Coût : apprentissage du système de types, étape de compilation, un peu de verbosité (réduite par l'inférence). Bénéfices : erreurs attrapées à la compilation (types incompatibles, propriétés inexistantes, fautes de frappe — qui en JS n'apparaîtraient qu'au runtime, voire en production), outillage supérieur (autocomplétion, navigation, refactoring sûr — un gain quotidien), robustesse et confiance, maintenabilité en équipe, excellent écosystème (Prisma, Zod). Pour un petit script jetable, JavaScript pur suffit ; pour une application sérieuse, TypeScript vaut largement l'effort.
Faut-il apprendre JavaScript à fond AVANT TypeScript, ou les deux ensemble ?
Il faut une bonne base de JavaScript AVANT de tirer parti de TypeScript, car TS = JS + types : on ne type bien que ce qu'on comprend. Apprenez les fondamentaux (async/await, modules, objets) en JavaScript pur, construisez des choses en JS, puis introduisez TypeScript quand JS est confortable — l'apprentissage de TS devient alors digeste (le système de types, pas le langage entier). Pas besoin d'être expert absolu avant TS, mais ne mélangez pas les deux apprentissages dès le départ.
Qu'apporte TypeScript par rapport à JavaScript ?