Debugging in VS Code

[00:00:00]
>> Steve Kinney: So debugging or so we got task JSON and we have this other idea of launch.json. Launch.json will start up your app and hook it up to some kind of debugger, right? What kind of debugger, it depends on what kinda debugging you want to do. You can debug Node apps, you can debug Python apps.

[00:00:29]
You can get extensions like we at temporal have one that will actually let you stop and debug an actual temporal workflow in our TypeScript, SDK, right? So, there are custom debuggers that can be written as well, but the built in ones are node, Chrome, Edge, I'm sure I wrote a list somewhere, a few other ones.

[00:00:48]
This, again, comes down to, I'm gonna just think about the questions in advance, which is for there are obviously other tools that do this as well, right? Node inspector has been around forever, bunn has its own inspector. And can you hook in to a running web app and use the Versus tool Versus Code debugger?

[00:01:14]
Yes, you know where else you have a debugger? Inside of Chrome, right? And so which one should you use? Well, I will show you the one relevant to this course. If you like this one, you should use this one. If you like the one that you use in Chrome, you should use that one.

[00:01:34]
I think that there is certain niceties to have it be in your editor. But let's be honest with ourselves the chrome dev tools are great [LAUGH] right, they're really good. So that's the thing as well. I don't need to run the formatter whenever this folder opens though. Cool, so you can hit run debug.

[00:01:57]
You can also hit this create launch.json file. Which is what we're gonna do in this case. You get a few options, what kind of debugger would you wanna do? I'm not running a bun project today. We got Node, we got a web app, which we could technically do.

[00:02:15]
So, all right, I'm gonna do it. Not wanna do, that I regret all my choices. Create a launch. Let's do the node one.
>> Steve Kinney: Think I wanna launch
>> Steve Kinney: Don't wanna look at my own notes. Source, and I think it's server.js.
>> Steve Kinney: I don't think I meant to make two of these, let's see.

[00:03:05]
>> Steve Kinney: Cool, I hope I did mess up with them. We gonna launch program which is gonna launch server.js. I don't wanna walk in any node internal please and the type is node. We got also add more configurations if you also wanted to attach to an electron main process.

[00:03:26]
Again, a lot of these are super good for electron actually coz there's just a lot of things to hook into. You can attach to a currently running process as well, so on and so forth. But now if you hit F5, you will see a large amount of sadness.

[00:03:46]
Already in use, 3,000 that makes sense.
>> Steve Kinney: So now you can see I've got the server running over here. Right, nothing yet to see in here. But the logos is running at 3,000. Really wish I had a task. Do I have a task for starting at the front end?

[00:04:11]
Did I do that? Was I smart enough or did I spend too much time talking. I'm pointing at things. No, I made one.
>> Steve Kinney: This is script dev.
>> Steve Kinney: Cool, so now let's also run the front end.
>> Steve Kinney: And let's say,
>> Steve Kinney: Start beat.
>> Steve Kinney: Now we'll also start up my client so we can go over to the client real quick.

[00:04:59]
We've got a task manager. Yeah, you thought you were gonna get out of workshop without a to-do list? Absolutely not. No, this is Front End Masters. We put to-do lists. So now I've got just the front-end running just so I can not write curl requests. And I've got the server running on 3,000, so let's just verify that task by croutons from store, great, went into a database.

[00:05:36]
Life is good. So now what I can do is, if I go into server.js, I've got this wonderful, amazing express app. And so we can do lots of things. We could say, I can get a test by ID that's not in the app. We can post, I like this.

[00:05:59]
We can go anywhere we want and we can add a little break point, right? And now what we can do is go ahead and use our app again. Read a book. Books are good. And I didn't even Cmd+Tab, right? I got sent back into VS Code, and we can see you type in title, and there is the title that passed in.

[00:06:38]
I can see the full call stack of Express's router and the middleware for next, so on and so forth, right? I have that break point in there and so it stopped me there. I have access to all of the variables if I was so inclined, right? So I could actually say title equals play video games, right?

[00:07:04]
And now I've changed that variable, and I've got these controls up here, which again, are continue, which is go past the break point, like step over it into a given function, out so on and so forth. Let me be honest to you, a lot of times I just wanna change something, hit play.

[00:07:20]
I wanna see that value is. It's like, where did undefined come from? Sometimes I will step up through the stack. If I'm like, I'm getting tired of putting console logs everywhere. Cuz, let's be honest, we all know how we really debug. So now I can go ahead and hit play and then obviously we changed the value before it went into the database and here it is, right?

[00:07:42]
And so if I wanted to see like, okay, what are all the things on, the request object at this point or the response. I have access to everything that is currently in memory. At that moment in time, I've frozen the world, right? I can evaluate almost anything that I would ever possibly want to do.

[00:08:02]
And then I can carry on along my merry way. So let's try it again. And we can say, I'm running out of things, read a book.
>> Steve Kinney: All right, and now for instance if we wanted to go up a level, you can see that we are somewhere in the express land of a layer with some kind of handle requests middleware.

[00:08:30]
And I can kind of step through, right? Little more helpful if I had more than one function or I put the break point somewhere else. But the fact of the matter is, this thing was already undefined by that point. Go up a function, go up. And instead of like, cuz even here, I'm not putting console logs in here.

[00:08:51]
I can put console logs in my code. I'm not going to node modules and hand editing some compiled code. That ain't happening. But at any given point, right? I can look at, I'm assuming,
>> Steve Kinney: I can see that the request object in this point and work with it as well, right?

[00:09:08]
And again, then I can move forward
>> Steve Kinney: Through my application as well, and see everything along and so you can go ahead and try out various different things. The joke is, it's sometimes very hard to come up with a fake problem to debug. But the idea that you can navigate around, and it's no different than the chrome tools, right?

[00:09:38]
You can also one of the other tasks that you can do in here is you can choose to hook it up to a chrome web app too. But also keep in mind that now it's nice coz you can see it in your own code,
>> Steve Kinney: But it's also Chrome DevTools are good too.

[00:10:02]
But yeah, you can basically set this up and when we look at extensions in a little bit this is super useful because you're spinning up almost a second version of VS code, right? And you can you're using a lot of this tooling to start and stop it from as well from here.

[00:10:18]
And so it is useful if one you have some kind of runtime that supports it, right? In our case, the TypeScript, JavaScript support is very good. I can't speak to, I don't know how good it is in Rust, right, or Ruby, or whatever. But you do have the ability to, kind of stop your code at various different break points.

[00:10:38]
And you can do things, everything you can do in Chrome you can do here too, right? And so you can have a stop on any uncaught exceptions, or even caught exceptions, right which always ends up poorly,
>> Speaker 2: But you can't rewind like you could in like Visual Studio, right?

[00:10:56]
You can't drag it back.
>> Steve Kinney: It will never be as good as Visual Studio, right? Even this stuff is really good, but the CTO at Temporal is a recovering Java engineer. And when I watch him use the Java IDs, [LAUGH] I'm not gonna lie to you, right? It's not as good, right?

[00:11:23]
You can pick various functions that you wanted to break on, normally I know what I'm kinda looking for along the way. The other thing is, let me go back to my code. You can edit the break point, but you can also after however many hits to that, not maybe not the first time.

[00:11:45]
But for some reason, we end up here too many times, I think also, the expression, you can put a conditional, which is if things were good, don't break here if we request is undefined or request that user somehow became undefined. Well, then, yeah, stop everything, I wanna go look at it, right, which is a lot nicer.

[00:12:07]
If you find console logging is great, I'm not gonna lie. We all do it, but if you find yourself just looking at the good things over and over as you try to get to the right things, you're better off of doing something.
>> Steve Kinney: All right, so now it is a conditional break point where I think it should be good at this point.

[00:12:34]
Wow, goes through AAA, we get to the break point, right? So theoretically, and I didn't realize this, that it knows the value of title in this moment with like Intellisense as well. Obviously, hopefully with this code, title can't be undefined. That's not a code path that should ever happen, given what's happening on line 52.

[00:13:00]
But if it was something that it ought not be, right? Sometimes it might be as simple as, hey, at some point, that query param for an ID that was a string should have been turned into a number. I don't know why that's not happening. You can then have those kinda conditional break points, and again, your code will stop at that moment.

[00:13:21]
You have full access to everything in memory. You can change those values to at least see if the rest of the code path works. Like I said before, you can, in this case, step over. We're still in the break point, but actually, everything was still good. Move to the next line of execution.

[00:13:40]
So here, we stopped a query with that conditional. But then I was like, okay, go to the next line. And I can do more stuff, right? And so I could say, here at this point.
>> Steve Kinney: Query was defined at this point. I can, at that point, move to the next line, which will be that res.sunstatus, right?

[00:14:08]
And I can see, I mean there's no new value there at this point, but you can go through each line and then all that memory is in scope. You can manipulate stuff, you can change stuff, which again, can make the process of working out a bug very easy.

[00:14:22]
And if you think about the amount of work we did to set it up, it was like, I made a launch.json that said run node and it under the hood passed inspect break, but it's not important. It did the right thing with very little work.
>> Speaker 2: If you don't set a break point, you can't have an option to break on all, you can't set it to break no matter what, right?

[00:14:46]
I mean, without the break point, it's not gonna stop.
>> Steve Kinney: You can have a break on caught or uncaught exceptions.
>> Speaker 2: Okay.
>> Steve Kinney: Right, or even particular names that error, right?
>> Speaker 2: Conditional.
>> Steve Kinney: Yeah, and even for code exception as well. So instead of just sort errors, a good practice sometimes is having express API error, right?

[00:15:09]
And you have various two kinds of errors so if I get this kind of error then stop me, right? And the one you just run node source server, your thing runs as normal, but if you run it with the launch config, then you'll be opted into these things, right?

[00:15:27]
Again, there are things like Node Inspector. Bun has Safari's dev tools that you can use. There are other options, but for the amount of work and the fact that I am in my editor and the fact that, I'm pretty sure, change the next line of code, right and before it gets to it is interesting when you need it as well.