VS Code Debugging

[00:00:00]
>> WebDevSimplified: Now we dove in deep into the Sources tab, but generally when I'm actually debugging my code, I prefer to do it directly inside of VS Code because VS Code is where I do all my code writing, so it makes sense that I would do it all directly inside of here. So next, I want to show you how you can set up VS Code to do your debugging directly inside of there. So if we scroll down a little ways to set this up, it takes a few steps, but overall it's not too complicated.

[00:00:23]
First, you need to go to the debugging sidebar. So I'm just going to make this a full screen since we don't need the developer tools anymore. Inside of here on the sidebar, this one that has the little bug icon with the play button, this is going to be your debug sidebar. Now mine looks like it got a little bit messed up, so let me just reload my screen real quick. There we go, and you can see there's a button right here for creating a launch.json file.

[00:00:44]
This is what you're going to want to click on to actually create a debug script. So click on that, create a launch file, and in our case we're developing a web app, so we're going to choose web app, and I like to use Chrome. So I'm going to choose web app Chrome. What that's going to do is it's going to create a file directly inside of this VS Code folder called launch.json. And if we look at this file, you can see it's telling us we want to create a Chrome execution for what we're going to be doing.

[00:01:07]
And essentially there's a lot of information on here to be able to tell you we're using Chrome for debugging. The only important thing that you need to care about though is this URL section. This is the URL for where your application is running. If you're using Live Server by default, that is 5500. So change this to 5500, and now we've essentially created a way for VS Code to hook directly into our browser to send us all that really nice debugging information.

[00:01:31]
Now if we go back to that debugging tab, you'll notice it looks a lot different. We have a play button up here to actually launch this application, as well as a bunch of stuff for our call stack, our variables, and so on. We already saw it in the browser. So if we click the play button, it'll run this particular script and open up our application. You'll see when I click that, it's opening up my brand new application inside of here, and if I was paused at any point in my application, it would pause me directly in VS Code.

[00:01:54]
So let me show you what that looks like. Let's just throw a debugger directly inside of our code right here. We're going to refresh our application. And of course I need to make sure I go live because I restarted my browser, so there we go. We are now live. So now if I just end this and restart it, we should hopefully see that it's pausing me directly inside my code right here. So now I can use VS Code to do all the same stuff I was doing in the browser.

[00:02:17]
I can click this to step over different things. I can step into different things to go into this set interval, and so on. I can also restart my entire application directly from the start. I have access to all the exact same variables. You can see I have my global variables and anything else. I can watch specific variables by adding them into here. For example, 2 + 6, that's going to give me 8 for my particular variable.

[00:02:37]
I have access to the full call stack inside of here. My call stack is relatively straightforward because I don't have a lot of stuff going on, but if we had more complex stuff, you can see it starts to show up inside of here. I also have the ability to see what files are being currently loaded. I can set the uncaught exceptions or caught exceptions. Again, I'd recommend toggling this uncaught exceptions.

[00:02:54]
You can set up all your different event listener related breakpoints. Every single thing that you could do directly inside the browser, you can do inside of here, which is really nice. The only thing you can't do inside of here is set up your DOM breakpoint event listeners, but those are something that I don't use super often. So for the most part, all of my debugging is done directly inside of VS Code because I find it's a much more enjoyable environment to work inside of, because now I have all the really nice stuff that I'm used to inside of VS Code, and I can see my code directly and if I see something I need to change, I can just go ahead and directly change that inside of my code.

[00:03:26]
Any questions about this? Yes. Does that work with live services as well, like externally? I see it says it's targeting localhost, but can I point that at like a dev site that I may be running in the... That is a good question. I don't know how well it would work if you pointed to a production site because many production sites, they like obfuscate their code. And also if you point it to a live site, you're not going to have that live code on your browser.

[00:03:49]
Most likely the live site is different code than what you have inside of your dev tools. It may work and actually hook up, but I'm not sure how well it would hook up to the actual files themselves that you have downloaded. It's generally a tool you're going to be using when you're doing local development. Also, I have a hard time believing it'll work because to make some of the connections work, sometimes the browser uses extra files in development mode that aren't there when you're in your production mode.

[00:04:12]
So I already talked about the debugger way of creating breakpoints, but also normally I have this disabled in my setting for recording, but there is a glyph that we can enable here. I'm just going to enable mine margins, there we go. So now on the side, you'll see this inside of yours. You can see these little red dots. If you click one of these red dots, that creates a breakpoint just like you would inside of the dev tools browser.

[00:04:32]
You can create a breakpoint here and you can also do lots of stuff with this breakpoint. You can remove it, edit it, and you can add in, for example, conditional breakpoints and so on. And if I want to, and I go into my debugger here, I can see that breakpoint. I can toggle on or off, or I can delete this breakpoint if I want to. So you have all that same control over breakpoints directly inside of VS Code as well.

[00:04:51]
Otherwise, pretty much all the controls and everything you work with is exactly the same as what you'd be used to in the browser. And like I said, I prefer VS Code for my debugging, but if you prefer the browser, you can use the browser. It's really personal preference. Yes, can you write to a file too, to capture certain things from your log versus just seeing it live? That's a good question. I don't know if there's a good way built into it to like export your logs to like a particular file directly, but if you are inside of like your dev tools, you could just directly copy what's inside your console so you can come into your console and you could just like, you know, Control A to select it all and copy it if you really wanted to do it that way.

[00:05:32]
But I don't think there's a good way to write it to a log, at least not that I know of, especially because the browser doesn't like to give you a lot of access to the file system. So there may be a way, but I don't use these types of tools for that kind of stuff as much, so I'm not really sure.