Useful Things to Know about the VSCode Debugger
- SHIFT + Command + D will open debugger window
fn
+f5
starts the debugger you have currently selected if it’s not currently running- But if it is already running,
COMMAND
+SHIFT
+f5
will restart it. tasks.json
is another file sorta likelaunch.json
that lets us define these other tasks! Don’t totally get how it’s different, but it does have a cool option calledproblemMatcher
that can do regex matching on stdout to see what a process is saying and do stuff depending on that!- In the
breakpoints
window on the left, you can see all breakpoints you have and if hover over one, a pencil icon appears. If you press that pencil icon, you can customize the breakpoint to only run in a certain condition is met! This seems useful because it means you can debug in such a way that you are automatically stopping code execution where maybe there is a known problem but you’re no sure how to replicate it but have suspicions that it might be caused when a certain variable isundefined
or something. - On a sort of similar note, in the super useful
variables
pane, you can add things to “watch”, which pics out particular variables of interested that you can watch mutate as they go if you’d like - In the
Call stack
pane, there is a lot going on I don’t totally understand, but for the current line you are using (I think it is highlighted automatically?) if you press the little icon that looks like a paragraph with anundo
symbol in it, that will take you back to your first breakpoint.
Gotchas
- Node breakpoints will be
unbound
if node, or thenpm
command you are using, isn’t run with the--inspect
flag. - Sometimes, if you aren’t able to get to code within maps, loops, and function invocations, then you need to press the
step into
button, which is like an arrow pointing down. This takes you into closures and scopes it seems.
- This is hopefully obvious to others, but it took me a few uses to understand that the configurations you define in your
launch.json
here:
{
"version": "0.2.0",
"configurations": [
{
"name": "Launch Server 🚀",
"type": "node",
"request": "launch",
"runtimeExecutable": "npm",
"runtimeArgs": ["run", "serve-debug"],
"cwd": "${workspaceFolder}/server",
"skipFiles": ["<node_internals>/**"],
"outFiles": ["${workspaceFolder}/server/dist/**/*.js"],
"env": {
"NODE_ENV": "development"
}
},
// This one works great but requires `npm run dev` to have been run already
{
"name": "Attach Chrome Debugger 🚀",
"type": "chrome",
"request": "launch",
"url": "http://localhost:5173",
"webRoot": "${workspaceFolder}/client",
"sourceMaps": true
},
{
"name": "Debug Frontend 🚀",
"type": "chrome",
"request": "launch",
"url": "http://localhost:5173",
"webRoot": "${workspaceFolder}/client",
"sourceMaps": true,
"preLaunchTask": "Run Frontend Dev Server"
},
],
}
Will show up as Debugger option here:
It’s just along with (potentially) reasonable presets that VSCode seems to create for you by scanning things like your package.json
. I think this relationship between the launch.json
and the configuration UI
would be a bit stronger if they’d go ahead and populate your launch.json
with the presets they generate so we could get a little 101 on what those presets look like in the form of a launch.json
.
I am still getting the hang of the valid options for the launch.json
but I’ll keep reading the docs and eventually understand all the options.
Here are materials I could pull together that might help with that
Top Level VSCode Debugging Guide
Variables Reference (things like ${workspaceFolder}
)
Tasks.json Guide
VSCode’s debugging guide section here covers Launch Configs and they remind us that we can use control
+ Space
to use intellisense to see suggestions for properties we can use for a specific debugger.
It’s probably at least reading through this section to understand the basics of launch.json
configs.