Visual Studio Code Can Do That?

Debugging with TypeScript

Burke Holland

Burke Holland

Visual Studio Code Can Do That?

Check out a free preview of the full Visual Studio Code Can Do That? course

The "Debugging with TypeScript" Lesson is part of the full, Visual Studio Code Can Do That? course featured in this preview video. Here's what you'd learn in this lesson:

Burke discusses how to launch and configure the debugger, and how to attach the debugger to the terminal in VS Code.


Transcript from the "Debugging with TypeScript" Lesson

>> Burke Holland: Let's move on to something a little more complicated, because often times, you're not running a very simple program like this that's just a single file that has no dependencies and no user interface. This is a rather contrived example, although you can use this. So what I'm gonna do here is I'm gonna move on to our next project here.

And this project is interesting, because we're using TypeScript. So I'm going to open the index file here and collapse the sidebar. And because actually it's open it again, because I've included a tsconfig here, which instructs TypeScript on what to do, I've given it just some basic instructions. Use the common JS module format, preserve JSX, use Source Maps, in line my Source Maps.

Because I've given it some basic instructions, VS code will now build this transcript for me. So I'm gonna go ahead and let's delete this file. I should learn the keyboard shortcut for deleting files. Somebody put that in the exercise, submit a pull request. So I've deleted all of the files here and remember, TypeScript doesn't run in the browser or Node.

All it does is transfile to JavaScript to which we need so we need those files. To get them back, what we can do is, Cmd+Shift B opens our build process. Because I've got the tsconfig, the TypeScript compiler automatically picks us up VS code says, well okay, what do you wanna do?

Did you wanna just build it? I can do that so let's build. So it'll build it and those files come back. Even better, I can say I can do Cmd+Shift+B and I can watch it. And now, I've got a watch process happening so anytime I make any changes to these TypeScript files, they get compiled over here into JavaScript files.

Now, while we're on the subject of TypeScript, I want to show you a little trick here in TypeScript that you can use. A lot of times, you have TypeScript files and you have JavaScript files. But you don't wanna see the JavaScript files, right? You just want to see the TypeScript files.

So what you can do here is, let's see, we can add our settings. Let's add some settings here. And you'll see that when I do that, it creates a settings.json file. And what I'm gonna do here is I'm gonna come down and just say files, exclude, and it it kind of gives me a list of things that it thinks I probably want to exclude.

We'll take these out and we'll put in, let's do **/*.js and then we can do, sorry, we have to say, true. And then let's duplicate that, bring it down, and let's say **/*, is true. Save that, and if you watch over to the side those files are gone.

Now they're not gone from the file system. They're just gone from the editor. And that just cleans up your editor a whole lot so you can see what you're looking at a little better. You could also use glob expressions up here to do multiple things in one line so you can do this.

I think it's **/* and then ***. You know what it is, it's like this. Watch this, like this or this.
>> Burke Holland: So any valid glob file, glob expression will work here. If you wanna look up globs, you can just Google that and try to figure out the Syntax.

But my point is you can create rather complex glob expressions that exclude all kinds of files. All right, so let's go ahead and keep in what we had before.
>> Burke Holland: Js and then let's do one more for the other one. Let's do **/*, and that will keep all of our JavaScript files out.

Help us to focus, remove this. Go ahead and save that, okay. So now we want to actually debug this application here. So to run this, what we actually need to do is open up a terminal here. So I'm just gonna run this from the terminal so you can see how this runs.

This program right here is a CLI program, so in other words, it doesn't run in the browser. It runs in Node, but it is activated from the CLI. So it's gonna prompt us for something. We have to input a color then it's gonna change the lamp color. All of that happens in the terminal so if we were to run this, what we would say is, we'd come down here to our terminal.

We have to make sure we're in the right folder here. So I'm gonna go up one and then move into and actually, I'll show you this. If you just add a new terminal instance, it'll ask you which one of these projects you wanna add? Remember I said terminals are specific to projects?

So we can just put one here, and now we're in the right folder. And now I can say here, I could run this by saying node index.js. Now, we're writing our file in the TypeScript, but we've to run it in the JavaScript, okay. So I'm gonna hit Enter here and it's gonna ask us to enter a color.

I'll put in green and the lamp color has been changed to green. Remember I told you that we can run JavaScript files with no configuration at all, right? So we can do that here, so let's do that. I'm going to press F5, okay, and it's gonna run and then it's gonna go away.

What happened, all right, so here's the deal. When you run applications in VS code like I just did, it runs them on an internal console. So that console prompt that we need in order to interact this application, it's there, but you can't see it. So what we need to do is instruct VS code on where to put the output or we need it to use the integrated terminal instead of the internal terminal.

In order to do that, we are now configuring the debug process so we need to add what's called a launch configuration or a launch config.
>> Burke Holland: What I'm gonna do is I'm gonna come over here to our debug panel and I'm gonna open the drop down list here.

And you can see here I've got several options for add config, I'm gonna say add config here. And it's gonna wanna know well, what are you trying to debug? We're debugging a node process so we'll choose node, and then it's going to create for us a launch config in the project to folder which it just did.

So if we come back to our explorer you can see there's now, its collapse some of this, make it a little easier and see this is our launch config. So let's look at this launch config. Right here, you can see that the name of it is launch program that type is node and the request is launch.

We've two types of launch configs or two types of requests, launch and attach. You can attach a debugger to a running process or you can use the debugger to launch and then it will attach itself. You will almost always use launch, it's much more common to use launch than attach but you can use attach and will look at that here a little bit, it's called launch program.

Whatever we change this name to is what will show up in the debugger. Here's what I mean by that, right now, if we go back to the right here you see it says launch program. If we change this to Launch CLI app, it changes up here too. So that's what the name does in the launch config.

The next thing it wants to know is what file is my entry point for running this application. So for us, it tries to guess for you, which is why it took a little bit of time for that launch config to be created. Because VS code is looking at my projects and it's trying to figure out okay, based on the file structure, I think this is what you want.

And then for our out files here, it just these are just where my JavaScript files live, which is my workspace folder. These configurations are all added by VS code automatically, I didn't have to do anything to get that, they're just there. Now, in order for us to get access to the terminal for the CLI app to run in the right place, we need to specify that we're going to come down.

In this case we're looking for the console so any console here, you can see we have external, integrated and internal. Right now we're internal so I'm gonna change that to integrated terminal here, and save that. And then now we should be able to add a breakpoint to the index.ts file, not the JavaScript file, to the index file, right here.

And then go ahead and run this from the debugger. So I'm gonna go ahead and launch it. All right, so in the case of this launch config, we actually don't need the out files. This is what I mean by configs being a little bit hard to set up, it's because you really do have to get them just right, and if you don't, the debugging just doesn't work.

And so I took out the out files, which I'm assuming was providing a bad path and let me go ahead and kill this application so we don't see that anymore. And the debugger should work now so let's go back to the index file here. I'm gonna put a break point and then let's go ahead and launch it.

And now see its opening the internal terminal or the integrated terminal here rather, and we can change the color, and then it will break on the breakpoint as you see right there. And now we can do logpoints and breakpoints and other types of things. What's very interesting is that we're debugging TypeScripts, but we're running JavaScript.

So you can see how VS code makes it so much easier to debug. Otherwise you'd have to set all this stuff up yourself, you have to set up Source Maps, that's not a lot of fun. And so VS code does that for you automatically, which is super nice.

So let's go ahead and continue on through this. Now another thing that you can do is you can set the VS code to auto attach its debugger to your process. So here's what I mean. A lot of times, people are like, cool story about the debugging, but I don't start my apps with the debugger.

I start them from the terminal with a start command or some sort of specific command that I'm running from MPM or my package JSON and I'd really like to keep it that way. I don't wanna change and if that's the case, what you can do is you can have VS code auto attach to that process whenever it fires up.

So let me show you how that works. In this case, let's say we were bent on running it like this where we wanted to run it this way. So if we do this, we get the exact same prompt there it goes. Now we want the debugger to attach when we run this application so what we can do is we can toggle on auto attach, okay?

I'm gonna debug auto attach and then what we have to do is we have to inspect we're saying node and then whenever you wanna use a debugger in node, you have to pass the inspect flag. Because there's a special debugging protocol that it opens when you do that on port 9229.

You don't need to know any of that information, just the fact that that's the way that it goes. So if we run this with node index.js, nothing's going to happen. What's another color? I'm running out of colors and nothing's gonna happen. But if we run it with node inspect index.js,

>> Burke Holland: Still nothing happens. Let's change it again, there we go. I'll tell you what, let's do it on, I think a better example, this might be on this one here, so I'm going to drop a breakpoint here and let's run into a new terminal instance. I'm going to do node inspect index.js and we want to toggle on auto attach.

I don't know if I just toggled it on or off, we're about to find out, there we go. Now it's on, I just had to toggle off. So now you can see that the debugger gets hit automatically just by virtue of me starting from the terminal. So just know that if you wanna start from the terminal you can and if you wanna still use the debugger, you can.

And you need to know about the auto attach feature so that you can auto attach the debugger whenever you run with the --inspect flag. And just remember, if you don't use the inspect flag, nothing is going to happen, because you are not in a debugging protocol for Node.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now