Debugging
| With source maps | |
| Launch config sketch | |
| Strategic logging | |
| Halve the code |
With source maps
Debugging starts with maps enabled. The debugger then shows TypeScript lines while the runtime executes the emitted JavaScript behind the scenes.
Build once with maps before attaching the debugger. Without that step breakpoints land on generated code and variables look unfamiliar.
tsc --sourceMap
app.js and app.js.map are written
Launch config sketch
A launch config tells the editor how to start the program and where to find the maps. Keep the sketch minimal: runtime, program entry, and map support on.
Press start, set a breakpoint on a TypeScript line, and step through. The call stack shows your functions, not generated helpers.
{
"type": "node",
"request": "launch",
"name": "Debug app",
"program": "app.js",
"sourceMaps": true
}
Strategic logging
When the debugger is overkill, log with purpose. Print a label plus the value at each boundary, then remove the lines once the fix lands.
Log inputs and outputs, not every step inside. Two well placed lines usually reveal which side of a boundary breaks the contract.
function discount(price: number, rate: number): number {
console.log("price:", price, "rate:", rate);
return price - price * rate;
}
Halve the code
For stubborn bugs, halve the suspect area. Disable half the logic, rerun, and keep the half that still fails. Repeat until one function remains.
The method feels slow but converges fast. Each step removes half the mystery with one run, so even large files shrink to a culprit in minutes.
const ids: number[] = [1, 2, 3, 4];
const even = ids.filter((n) => n % 2 === 0);
console.log(even);
Next: Project references
Article author: Arthur Isaev
