Comment surveiller ts-node et recharger lors des modifications de fichiers : guide des erreurs

Comment forcer ts-node à se recharger lors des modifications de fichiers : analyse des vrais pièges

Imaginez : vous écrivez un serveur en TypeScript, vous lancez ts-node, vous apportez une modification — et rien ne se passe. Vous devez arrêter manuellement le processus, appuyer sur Ctrl+C, relancer. Cela vous dit quelque chose ? Ce problème a rassemblé des milliers de vues sur Stack Overflow, et pour cause : la configuration du watch et reload pour ts-node est un vrai casse-tête.

Dans cet article, je ne vais pas simplement vous donner une recette toute prête. Nous allons analyser le top des erreurs que même les développeurs expérimentés commettent, et je vais vous montrer comment les éviter. Vous découvrirez pourquoi ts-node --watch ne fonctionne pas "prêt à l'emploi", en quoi ts-node-dev est meilleur que l'approche classique, et comment ne pas tuer les performances du serveur en cours de route.

Pourquoi ts-node ne se recharge-t-il pas tout seul ?

Mettons les choses au clair tout de suite. ts-node n'est pas un serveur de développement. C'est un transpileur TypeScript vers JavaScript qui exécute le code dans l'environnement d'exécution Node.js. Il n'a pas de mécanisme intégré de surveillance des modifications de fichiers (file watcher). Lorsque vous écrivez ts-node app.ts, il exécute simplement le fichier et termine son travail.

Pour obtenir un rechargement automatique lors des modifications de fichiers, vous devez utiliser des outils externes. Et c'est là que les choses deviennent intéressantes.

Top 5 des erreurs lors de la configuration du watch et reload pour ts-node

J'ai rassemblé les pièges les plus courants dans lesquels les développeurs tombent. Passons en revue chacun avec des exemples et des solutions.

Erreur n°1 : Utilisation du flag --watch sans le bon outil

Beaucoup écrivent dans le terminal :

ts-node --watch app.ts

Et sont surpris que rien ne fonctionne. Le problème est que ts-node n'a pas de flag --watch dans son installation standard. Cette commande est simplement ignorée ou génère une erreur.

Solution : Utilisez nodemon en combinaison avec ts-node. Voici la commande correcte :

npx nodemon --exec ts-node app.ts

Ou, si vous voulez l'enregistrer dans package.json :

{  "scripts": {    "dev": "nodemon --exec ts-node src/index.ts"  }}

Cela forcera nodemon à surveiller les modifications dans les fichiers et à redémarrer ts-node à chaque sauvegarde.

Erreur n°2 : nodemon ne voit pas les modifications dans les fichiers .ts

Vous avez configuré nodemon, vous sauvegardez un fichier, et il reste silencieux. Pourquoi ? Par défaut, nodemon ne surveille que les extensions .js, .json et quelques autres. .ts n'est pas dans la liste.

Solution : Spécifiez les extensions explicitement :

nodemon --watch src --ext ts --exec ts-node src/index.ts

Le flag --watch src limite la zone de surveillance au dossier src (pour ne pas surveiller node_modules). Et --ext ts ajoute les fichiers TypeScript à la liste des extensions surveillées.

Vous pouvez également créer un fichier nodemon.json :

{  "watch": ["src"],  "ext": "ts",  "exec": "ts-node src/index.ts"}

Erreur n°3 : Conflit avec tsconfig.json — résolution de module incorrecte

Situation typique : vous utilisez ts-node avec nodemon, mais au lancement vous obtenez des erreurs comme Cannot find module ou Unknown file extension ".ts". Le plus souvent, le problème vient des paramètres de tsconfig.json.

Exemple de tsconfig.json problématique :

{  "compilerOptions": {    "module": "ESNext",    "moduleResolution": "bundler",    "target": "ES2020"  }}

Problème : ts-node fonctionne dans l'environnement Node.js, alors que module: "ESNext" avec moduleResolution: "bundler" sont conçus pour des bundlers comme Webpa