Visual Studio Code

Debugging Node with VS Code

Visual Studio Code

Check out a free preview of the full Visual Studio Code course

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

Mike illustrates how to debug node applications within VS Code by troubleshooting the course demo application.


Transcript from the "Debugging Node with VS Code" Lesson

>> Mike North: So you're gonna start with MPM run debug inspect, I think it's inspect. Let me double check here, cuz I know I said attach earlier. It is inspect, attach was a typo and I will fix that. Here it is, that's the proof. So this is correct. You are gonna open the debugger side panel, create a launch configuration.

This has been done for you already. We will explain in detail what this means line by line when you get into launch configuration. Take it on faith for now. You will press the launch button and you will end up being like where I am right now. So let's talk a little bit about the particulars of debugging.

I mentioned there's this new protocol for talking to a job discript run time, that is what we mean by this inspector protocol. If you see legacy protocol you might also see v8debugger protocol that is the old stuff. That was the only option before node six and then, or six point something, and then from six point something up to eight, we could use either.

And now in node eight, you can only use the new one, right? So launch versus attach. When we talk about launch that's one button and your app is booted and it's running. Attach means you're looking for something that is already started and you're gonna sort of connect to that debugger and operate off of it.

I will show you a conditional breakpoint, there are two things that we can do that are pretty cool here. Let's actually jump in and do that. Conditional breakpoint. So this is the entry point for our server. What I can do here is, I'll say, edit breakpoint. And I've got two options here.

An expression and a hit count. If I say hit count and I set this equal to, actually, let me put this in a more reasonable place. This will only get hit once. So let's look in routes
>> Mike North: Grocery, you don't need to worry about this. Just watch along.

Okay, so here getting categories. So this happens every time the app is started up, its how we know what the rows are gonna be. So I'll say, I want this break point when it is equal to 3 to freeze, right? So the third time we hit this freeze.

Has anyone tried to set a break point inside a loop before? Where you're like, you have to hit next, next, next, next, next, next, next. So here, you can say, you can look through your list of items, and see, hey, looks like it's the 1,758th item in here.

Let's say, when our hit count is this, freeze. And it sort of will track that for you. So were gonna, oop, the address is in use, interesting, based on the errors is here as well. Okay, so lets killall node in case there is something lingering back there were gonna start it back up npm run debug:inspect.

And then we're gonna bring our debugger back
>> Mike North: And attach. And you'll note that it starts with the break point on the first line. This is to give us a chance to attach. It doesn't run away from us. And sort of waits to start until we attach. So I'm gonna run.

Something is still on 3000.
>> Mike North: There you go.
>> Mike North: Come on node, why won't you die? It's too robust.
>> Mike North: All right, once more.
>> Mike North: Hey, no errors. Okay, so we're running, that's fun. We're gonna go to our app, we're gonna refresh, what's going on here?
>> Mike North: All right, I'm gonna dial back type script a little bit.

Feel free to do this in your own thing as well. We'll allow that any type again.
>> Mike North: Looks like I left something, left a mess. My previous solution.
>> Mike North: And it's still waiting. Gotta attach and run.
>> Mike North: Nope, okay, it looks like I'll have to fix this on the fly here.

So home/index and something is unhappy here.
>> Mike North: Categories
>> Mike North: And I left a c somewhere.
>> Mike North: ArrayLike<any>
>> Mike North: On line 29, what's going on here? Here we go
>> Mike North: In here, we can say this.state.categories as Array, something like that. There we go, and we're back. Don't worry, I will have you guys start working on this.

Okay, so now it should work. And we're at a break point that I had set earlier, ignore that please. Great, so now the app is loaded, so that should be one time, two times, three times. Maybe we have to over shoot. I do not trust it anymore. I think we lost it through our coded thing here.

Let me double check real quick. Grocery
>> Mike North: Hit Count, I'll just do 2.
>> Mike North: One, two, so only on the second time we hit it. So that's the first one and here's the other type of conditional break point. We can have an expression and when this expression evaluates true, only then will we stop at this break point.

So I can see right now, I've got context. Let's see, I can run some stuff actually in this debug console to see what's going on, ctx.params, let's see what that looks like. Not interesting query. That might be interesting.
>> Mike North: This is a less interesting one for that kind of thing.

Let's do items.
>> Mike North: Just looking for an appropriate. Nope, this is wrong. Rout, it should be in here. Categories, there it is, items. Okay, so, we'll get rid of this breakpoint, we're currently paused there, so here, I'm gonna stop here and we will just freeze the first time.

So here we got a query category is bakery. So I'm gonna edit the breakpoint and say only when ctx.query,
>> Mike North: Category is fruit, should we stop. Now we've stopped at 'fruit'. So that's like, only in this specific situation should I freeze here. So that is a conditional breakpoint.

You have support for both of those in code.
>> Mike North: So restart frame, that is interesting. Let's see if we can make that work. Okay,
>> Mike North: Should, actually we got rid of that.
>> Mike North: So the way that works is you just pick one of these stack frames here in the call stack.

So you see this represents handle requests and then parse the body and this is sort of trickling all the way down to finding the right function to use. Dispatch this thing to the appropriate route, and then we finally got this. So if I wanted to stop up here, I can actually click on this anonymous function.

And say, restart frame.
>> Mike North: And now, I haven't actually made a new API call. I've kind of taken a little bit of a step back in my debugger. I didn't have to refresh my browser, it has sort of traveled back in time, keeping me frozen. And then, I could manipulate things and play it forward.

Really, really cool powerful thing. And you are only gonna get it when you have a crack team working on your debugging tools, cuz these are specific run time protocols that have to be used. And all of these different job descript run times are optimized for different things. It is great that we have many of them, right?

Does things that V8 doesn't do yet. V8 does things the tracker hasn't implemented yet. And then, we've got JS Core, which is Safari's runtime. And it is really, really, really fast, but it doesn't have some of the modern language features that V8 has been pushing on. And then, we've got Servo coming up.

Which is this new JavaScript runtime for the next generation of Mozilla of Firefox and it is built with rust and handles parallelism really really well. I mean, there believing engine a totally different dimension here. So it's starting to get to the point where it's not really generic debugging and we might have a use for hacking into some of these specific features, cuz restarting a stack firm is pretty freaking cool.

>> Mike North: All right, moving on, finally, i just wanted to say skipping code if you don't know what that is, it's just black boxing where you would basically say if I didn't write it don't step through it, right? This means you're not gonna dig deep into React or into Express or something.

This also like this may be referred to as black boxing or a SmartStep is one of the terms that the vscode team uses. It's just trying to let you, trying to decide what is interesting to you. And to not take you like out into the woods into your dependencies, because in that mode you would say look I trust that they have a thousand tests for this library like, that is probably working fine.

I am working on something I no test for yet, so let's step through my code and who we can have need to go through their stuff.

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