Debugging von TypeScript-Code: Werkzeuge und Techniken für Entwickler

Debugging von TypeScript-Code: Bugs in Aufgaben verwandeln

Haben Sie schon einmal eine Stunde damit verbracht, einen Fehler zu suchen, der sich als einfacher Tippfehler in einem Variablennamen herausstellte? Oder haben Sie sich dabei ertappt, dass console.log das einzige Werkzeug ist, das Sie verwenden? Willkommen im Club. Debugging ist nicht nur „Fehler fangen“, sondern eine ganze Kunst, zu verstehen, wie Ihr Code tatsächlich funktioniert.

TypeScript verleiht dieser Geschichte einen besonderen Reiz. Einerseits eliminiert die statische Typisierung bereits während der Kompilierung eine ganze Klasse von Fehlern. Andererseits wird das Debuggen „on the fly“ schwieriger, sobald der Code in JavaScript kompiliert ist: Sie schreiben in TS, sehen aber im Browser kompiliertes JS. Wie verlieren Sie sich nicht in diesem Labyrinth?

Heute zeige ich Ihnen die realen Debugging-Techniken für TypeScript-Code, die ich selbst verwende. Kein überflüssiges Wissen – nur praktische Werkzeuge, Beispiele und Lifehacks, die Ihnen Nerven und Arbeitsstunden sparen.

Warum unterscheidet sich das Debugging von TypeScript vom Debugging von JavaScript?

Die Hauptbesonderheit von TypeScript ist die Transpilierung. Sie schreiben Code mit Typen, Generics und Interfaces, während der Browser oder Node.js sauberes JavaScript erhält. Das bedeutet, dass Sie beim Debuggen auf kompilierten Code schauen, der sich stark vom Original unterscheiden kann: Variablennamen können geändert, Generics gelöscht und Interfaces ganz verschwunden sein.

Die Lösung – Source Maps. Dies sind Zuordnungskarten zwischen dem ursprünglichen TS und dem kompilierten JS. Ohne sie wird das Debuggen von TypeScript zum Kaffeesatzlesen.

Einrichtung von Source Maps: Der erste Schritt zur Transparenz

Damit der Browser oder Debugger versteht, welche TS-Zeile welcher JS-Zeile entspricht, muss die Generierung von Source Maps in tsconfig.json aktiviert werden:

{\n  "compilerOptions": {\n    "sourceMap": true,\n    "outDir": "./dist",\n    "target": "ES2020",\n    "module": "commonjs"\n  },\n  "include": ["src/**/*"]\n}

Jetzt erscheint bei der Kompilierung neben jeder JS-Datei eine .map-Datei. Der Browser (Chrome, Firefox) lädt sie automatisch, und Sie können Haltepunkte direkt im TypeScript-Code setzen.

Wichtig: In der Produktion sollten Sie Source Maps besser deaktivieren oder versteckte Endpunkte verwenden, um den Quellcode nicht den Benutzern preiszugeben. Konfigurieren Sie dies über Umgebungsvariablen:

// tsconfig.prod.json\n{\n  "extends": "./tsconfig.json",\n  "compilerOptions": {\n    "sourceMap": false\n  }\n}

TypeScript-Debugging-Werkzeuge: Ihr Arsenal

1. VS Code – Integrierter Debugger

Visual Studio Code ist wohl die beste Umgebung zum Debuggen von TypeScript. Der integrierte Debugger kann Source Maps lesen und Breakpoints direkt in .ts-Dateien setzen. Hier ist eine minimale Konfiguration für launch.json:

{\n  "version": "0.2.0",\n  "configurations": [\n    {\n      "type": "node",\n      "request": "launch",\n      "name": "TS-Debugging über 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}

Jetzt können Sie F5 drücken und gelangen sofort in den Debugger. Setzen Sie rote Punkte links neben den Zeilennummern – sie funktionieren auch, wenn Sie TypeScript-Code mit Generics und Dekorateuren debuggen.

Lifehack: Verwenden Sie debugger; direkt im Code – das entspricht dem Setzen eines Breakpoints, erfordert aber keine Maus.

2. Chrome DevTools – Frontend-Debugging

Für Frontend-Projekte mit TypeScript (React, Angular, Vue) sind Chrome DevTools ein Must-have. Öffnen Sie den Tab Sources, suchen Sie Ihre Datei im Ordner webpack:// oder src – wenn Source Maps richtig konfiguriert sind, sehen Sie den ursprünglichen TypeScript-Code.

Nützliche Funktionen:

\n
• Conditional breakpoints