Debug TypeScript applications using the VSCode debugger

Rich Buggy
InstructorRich Buggy
Share this video with your friends

Social Share Links

Send Tweet
Published 5 years ago
Updated 3 years ago

The VS Code debugger provide a rich debugging experience allowing you to step through your code line by line and view variable values. In this video you will learn how to enable source maps for TypeScript and use them with the VS Code debugger so you can write and debug code using the TypeScript source while Node executes the compiled output.

Rich Buggy: [00:00] 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.

[00:21] 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.

[00:36] 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.

[00:51] 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.

[01:08] 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.

[01:28] 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.

[01:49] 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.

[02:09] 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.

[02:25] 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.

[02:37] I'll left the setting as ES5, which doesn't support the syntax I'm using with the args parameter. To emulate this, typescript needs to output additional lines of JavaScript that all map back to this one line of code.

[02:52] 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.

[03:14] 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.

[03:29] 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.

[03:37] You can do this using step out. To restart debugging, use the restart option. Finally, to stop the debugger, I'll click stop.

egghead
egghead
~ 5 minutes ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today