Pourquoi ce sujet est important
TypeScript n’est pas un autre runtime : il ajoute une analyse statique à JavaScript puis produit du JavaScript. Le choix porte donc sur le niveau de contrôle souhaité dans le code et sur le coût d’outillage accepté.
Ce que TypeScript apporte
Les types décrivent fonctions, objets et contrats. L’éditeur peut compléter, renommer et détecter des incohérences avant exécution. Le bénéfice augmente avec le nombre de modules, de contributeurs et de refactorisations. Les types servent aussi de documentation proche du code.
Ce qu’il ne garantit pas
Les types disparaissent à l’exécution. Une réponse API, un formulaire ou une variable d’environnement reste non fiable. Utilisez validation runtime et gérez les erreurs. any, assertions et types trop larges peuvent donner une impression de sécurité sans preuve.
Quand JavaScript suffit
Un script court, une expérimentation ou un projet maintenu par une petite équipe peut rester en JavaScript. JSDoc et un mode de vérification apportent déjà de l’aide. La simplicité est utile lorsque la durée de vie et le domaine sont limités.
Quand choisir TypeScript
Pour une application longue durée, une bibliothèque, une API partagée ou une équipe nombreuse, TypeScript réduit de nombreuses erreurs de contrat. Il facilite les migrations de modèles de données et les changements transversaux. Il faut cependant définir une configuration stricte et commune.
Concevoir de bons types
Modelez les états possibles au lieu d’ajouter des champs optionnels partout. Utilisez unions discriminées, types génériques avec mesure et types générés depuis les schémas lorsqu’ils sont la source de vérité. Évitez de dupliquer manuellement le même contrat côté serveur et client.
Migrer progressivement
Activez TypeScript, commencez par les modules stables et les frontières, puis réduisez les échappatoires. Autorisez temporairement JavaScript si nécessaire. Ajoutez le type-check à la CI. Une migration big bang bloque souvent le produit sans améliorer les zones les plus risquées.
Outillage et performance
Le typage ajoute un temps de compilation et de CI. Séparez transpilation rapide et vérification si le projet l’exige. Épinglez la version, partagez tsconfig et surveillez les types complexes qui ralentissent l’éditeur.
Exemple concret
Une API JavaScript grandit de trois à vingt développeurs. L’équipe génère les types depuis le schéma, migre d’abord les services et active strict progressivement. Les payloads externes restent validés. Les refactorisations deviennent plus sûres sans interrompre les livraisons.
Les erreurs fréquentes
- croire que TypeScript valide les données externes
- utiliser any partout
- multiplier les assertions as
- dupliquer les types client et serveur
- migrer tous les fichiers en une fois
- ignorer les erreurs du type-check en CI
Checklist
- [ ] Durée de vie et équipe évaluées
- [ ] Configuration stricte définie
- [ ] Frontières runtime validées
- [ ] Types générés si possible
- [ ] Échappatoires suivies
- [ ] Type-check dans la CI
- [ ] Migration progressive planifiée
FAQ
TypeScript est-il plus lent en production ?
Le code exécuté est du JavaScript. Le coût principal est au développement et au build.
Faut-il typer un petit script ?
Pas forcément. JSDoc ou JavaScript peuvent suffire si le risque et la durée sont faibles.
TypeScript remplace-t-il les tests ?
Non. Il détecte des incohérences de forme, pas toute la logique métier ni le comportement runtime.
Comment commencer une migration ?
Par les frontières et modules à forte valeur, avec allowJs temporaire et strict progressif.