June 14th, 2019 - 5 min read
I highly recommend listening to the podcast Debugging Tools + Tips for more tips about debugging.
They are also mentioning a video from James Q. Quick on Youtube about the setup for VS code. You can find the tutorial video for front-end setup for Create-React-App here.
In this post, I'd like to show how to set up a proxy server in VS code so that the debug information is available with-in your editor (like in the mentioned Youtube video).
Open your project folder and click on the debugger symbol in the sidebar. Next click on the dropdown and select add a configuration (see screenshot below).
After clicking on the gear icon close to Add configuration
it will open a dropdown with some proposals where we're selecting Chrome
because we'd like to debug with Chrome.
This selection will create a folder .vscode
with a launch.json
file in it with the following content:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "chrome",
"request": "launch",
"name": "Launch Chrome against localhost",
"url": "http://localhost:8080",
"webRoot": "${workspaceFolder}"
}
]
}
The .vscode
folder is for project-related configuration files and the launch.json
file is for the debug session configuration. There are more files like setttings.json
& extensions.json
- you can learn more about them here.
Now we have to change the port of the default configuration to match our development server e.g. port 3000 for a CRA app or in my case 1234 for a Parcel setup.
Before starting the debugging we have to verify that we're having the Debugger for Chrome
extension installed. Checking is possible by pressing Ctrl+Shift+P
or Cmd+Shift+P
and enter install extension
- and install msjsdiag.debugger-for-chrome
if it's not already installed.
So we have everything in place now - by selecting the previously created configuration and hitting the green play button it will open Chrome and our dev server URL localhost:1234
.
As we haven't added a breakpoint yet, there won't be an interruption of our app and that's the next thing we have to add.
Go back to VS Code and click on the gutter in the line where the program execution should pause.
If there is a message Unverified breakpoint
check that the project build configuration is generating source maps in the dist
folder.
It's also possible that the source map is not found and that can be fixed by changing the configuration like this:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"type": "chrome",
"request": "launch",
"name": "Launch Chrome (localhost:1234)",
"url": "http://localhost:1234",
"webRoot": "${workspaceFolder}",
"sourceMapPathOverrides": {
"*": "${webRoot}/src/*"
}
}
]
}
Please notice the added sourceMapPathOverrides
that will match source map files with the filename src.hash.js.map
for the current project.
So if the breakpoint is now accepted the paused debug session should look similar to the following screenshot:
In the debugger panel, we can check variable values in each scope. So we can exactly see the data of all variables and that's pretty handy as there is no need to log every variable that we're interested in.
The call stack that was executed to get to the location of the breakpoint is visible in the Call stack
section of the sidebar. That's useful if you'd like to know what called your function.
It's also possible to hover with the mouse cursor over variables to show their values.
By configuring the breakpoints we can add conditions when the program execution should be stopped. By default, it will just stop when the program is hitting the line in question. By right-clicking on the red breakpoint symbol and selecting edit there are the following options:
console.log
that are displayed in VS code Debug console
and in the browser console.For front-end projects I will debug with console.log
and debugger
statements - so I can debug in the browser. Because I'm not seeing a big improvement if I'm doing it in VS Code. Also debugging in Chrome or Firefox is more powerful than in Code.
Just to mention a few points that are missing during debugging with VS code:
But I think debugging a Node.js app will be useful because there is no other way to stop and look into your code - so I'll give it a try when I'm working on the next backend code.