Débogage de code TypeScript : transformons les bogues en défis
\n\nAvez-vous déjà passé une heure à chercher une erreur qui s'est avérée être une simple faute de frappe dans le nom d'une variable ? Ou vous êtes-vous surpris à penser que console.log est le seul outil que vous utilisez ? Bienvenue au club. Le débogage n'est pas seulement une « chasse aux bogues », c'est tout un art de comprendre comment votre code fonctionne réellement.
TypeScript ajoute un charme particulier à cette histoire. D'un côté, le typage statique élimine toute une classe d'erreurs dès la phase de compilation. De l'autre, une fois le code compilé en JavaScript, le déboguer « à la volée » devient plus complexe : vous écrivez en TS, mais vous voyez dans le navigateur du JS compilé. Comment ne pas se perdre dans ce labyrinthe ?
\n\nAujourd'hui, je vais vous montrer les techniques réelles de débogage de code TypeScript que j'utilise moi-même. Rien de superflu – seulement des outils pratiques, des exemples et des astuces qui vous épargneront des nerfs et des heures de travail.
\n\nPourquoi le débogage TypeScript diffère-t-il du débogage JavaScript ?
\n\nLa particularité principale de TypeScript est la transpilation. Vous écrivez du code avec des types, des génériques et des interfaces, tandis que le navigateur ou Node.js reçoit du JavaScript pur. Cela signifie que lors du débogage, vous regardez du code compilé qui peut différer considérablement de l'original : les noms de variables peuvent être modifiés, les génériques effacés et les interfaces complètement disparues.
\n\nSolution – les Source Maps. Ce sont des cartes de correspondance entre le TS source et le JS compilé. Sans elles, le débogage TypeScript devient un jeu de devinettes.
\n\nConfiguration des Source Maps : premier pas vers la transparence
\n\nPour que le navigateur ou le débogueur comprenne à quelle ligne TS correspond une ligne JS, vous devez activer la génération des source maps dans tsconfig.json :
{\n "compilerOptions": {\n "sourceMap": true,\n "outDir": "./dist",\n "target": "ES2020",\n "module": "commonjs"\n },\n "include": ["src/**/*"]\n}\n\nDésormais, lors de la compilation, un fichier .map apparaîtra à côté de chaque fichier JS. Le navigateur (Chrome, Firefox) le chargera automatiquement, et vous pourrez placer des points d'arrêt directement dans le code TypeScript.
Important : en production, il est préférable de désactiver les source maps ou d'utiliser des points de terminaison cachés pour ne pas exposer le code source aux utilisateurs. Configurez cela via des variables d'environnement :
\n\n// tsconfig.prod.json\n{\n "extends": "./tsconfig.json",\n "compilerOptions": {\n "sourceMap": false\n }\n}\n\nOutils de débogage TypeScript : votre arsenal
\n\n1. VS Code – débogueur intégré
\n\nVisual Studio Code est sans doute le meilleur environnement pour déboguer TypeScript. Le débogueur intégré sait lire les source maps et placer des points d'arrêt directement dans les fichiers .ts. Voici une configuration minimale de launch.json :
{\n "version": "0.2.0",\n "configurations": [\n {\n "type": "node",\n "request": "launch",\n "name": "Débogage TS via ts-node",\n "runtimeArgs": ["-r", "ts-node/register"],\n "args": ["${workspaceFolder}/src/index.ts"],\n "sourceMaps": true,\n "cwd": "${workspaceFolder}",\n "protocol": "inspector"\n }\n ]\n}\n\nVous pouvez maintenant appuyer sur F5 et accéder directement au débogueur. Placez des points rouges à gauche des numéros de ligne – ils fonctionneront même si vous déboguez du code TypeScript avec des génériques et des décorateurs.
\n\nAstuce : utilisez debugger; directement dans le code – cela équivaut à placer un point d'arrêt, mais sans utiliser la souris.
2. Chrome DevTools – débogage frontend
\n\nPour les projets frontend en TypeScript (React, Angular, Vue), Chrome DevTools est un must. Ouvrez l'onglet Sources, trouvez votre fichier dans le dossier webpack:// ou src – si les source maps sont correctement configurées, vous verrez le TypeScript original.
Fonctionnalités utiles :
\n- \n
- Points d'arrêt conditionnels