Rich Buggy: To demonstrate debugging typescript in VS Code, I'll start by creating a simple application. In the source folder, I'll create a file called logger.ts that exports a function called logger. This function will accept a variable number of arguments, and log them to the console twice.
I'll then add an index.ts in my source folder. In this file, I'll import the logger function from logger, then loop through the numbers 09, explaining each one twice, using it.
Next, I'll create a typescript config file using the tsc-init command. In the config file, I'll set the outDir to the dist folder to separate sourced and compiled code.
I'll enable sourced maps, so the compiled code can be mapped back to the source code during execution. Now, I'll compile my code using the TypeScript compiler with the -p option to specify my config file.
You can see the generated code and the source map files in the disk folder. I'll switch to the debug view in VS code using the shift command D keyboard shortcut from inaudible . As I don't have a debug configuration yet, I'll need to add one for node.
The default value for program is set towards the debugger with a file that's currently open in the editor. I'm going to change that to our compiled code in disk/index.js. I'll remove out files and enable source maps which tells the debugger to use source maps if they exist.
Before launching the debugger, I'll set a break point inside my index file. When I run the program using the debugger, it will now stop at the break point in my source. I can inspect the value of variables inside the debug window or by moving my mouse over the variable in the editor.
If I click continue, the debugger will continue execution until the code finishes where it reaches the next break point. I only have one break point, so it stops at the same line, but the variable named counter had been incremented.
To see the code inside a function being executed, use step in. It's important to understand that your TypeScript target setting will impact your debugging experience.
This means I need to step through my code a few times before it leaves line one, as multiple lines in the generated file all map back to this one line in the source. If I had targeted a more recent version, like ES2015, that supports this syntax, the debugger would have stopped on line two instead of line one. I can now continue to step through the rest of my function.
When I try to step past the end of the logger function, it takes me to the next line of code after logger was called from index, which is the top of my four-loop. I'll just continue to get back to my break point, and step into the logger function again.
Sometimes, you'll step into a function, then realize you don't want to continue debugging it, but you would like to continue from where the function ends.
You can do this using step out. To restart debugging, use the restart option. Finally, to stop the debugger, I'll click stop.