Blog A.Wolf

Blog Posts

No results for 'undefined'Powered by Algolia

Debugging a Web App in VS Code

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).

Setup

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). Screenshot add configuration

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.

Debugging

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: Screenshot Debug Session

What's possible now

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:

  • Hit count: Breaks after the line was executed x times
  • Expression: Creates a conditional with variables in local scope that will pause execution.
  • Log message: Triggers a console.log that are displayed in VS code Debug console and in the browser console.

Final thoughts

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:

  • Advanced breakpoints for events e.g. break on any scroll event
  • Debugging network requests
  • React & Redux-dev-tools

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.

©2024 Alexander Wolf