VSCode debugging

What I don’t think a lot of VSCode users are used to is constantly living with the debugger turned on. Most web devs grew up in a world without Visual Studio, so console.log is the norm. However anyone who used Visual Studio for Visual Basic or C# development will know the power of constantly using and setting break points in your code. I’ve long ago stopped using Visual Studio, but here’s rough notes of what I did to bring debugging love back.

The debugger attaches a firefox/chrome extension to a running server and debug session.

So you must:

1. npm run dev
2. npm run dev:workers (in packages/server)
3. Start debug session via VS Code (see below)

No more logs

So trying to get VSCode debugging working again so that I don’t keep pissing around with console.log.

Following on from Speedy deployment.

I have the Firefox debugger extension installed.

I now make sure I add things to my .vscode/launch.json so that I have them in the future for when I forget.

Here is the launch.json configuration:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch index.html",
            "type": "firefox",
            "request": "launch",
            "reAttach": true,
            "file": "${workspaceFolder}/index.html"
        }
    ]
}

Note: that is attaching to a file – we want to attach to the next.js running URL

You can also create something very similar by clicking the ‘Add configurations’ button at the bottom when you have the launch.json file open.

Now we’re using next so need to hook into that. There are quite a few tutorials for this:

• dev.to – I followed this first – but it seems it has since been added to the official page
• Offical Next.js debugging – good details for server-side and client-side debugging launch.json
• Simple Next.js – has a nice example about conditional breakpoints
• VSCode recipe
• Hackernoon
• StackOverflow

For the Next.js specific launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "firefox",
            "request": "launch",
            "reAttach": true,
            "name": "Next: Firefox",
            "url": "http://localhost:3001",
            "webRoot": "${workspaceFolder}"
        }
    ]
}

Note the url and webRoot settings.

Setting up Firefox to connect

You need to enable remote debugging.

Now you should be able to the ‘Run and Debug’ side bar and run the “Next: Firefox” as in the name setting above.

I added a breakpoint to a file, which showed up as a grey circle next to the line numbers. I was expecting a red filled circle. When you run the debug session the breakpoint doesn’t stop there. The error comes down to the path settings because next.js isn’t running at the root of the workspace:

See the notification in the bottom corner:

This is similar to the dev.to Bonus: If your Next.js code is not at the root of your workspace section, but here we have pathMappings instead of sourceMapPathOverrides.

Note: I adjusted the webRoot to include the packages path after fixing this for Chromium, but it still requires the pathMappings.

I clicked on ‘Yes’ in the above message. It then created the pathMappings launch.json as:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "firefox",
            "request": "launch",
            "reAttach": true,
            "name": "Next: Firefox",
            "url": "http://localhost:3001",
            "webRoot": "${workspaceFolder}/packages/client",
            "pathMappings": [
                {
                    "url": "webpack://_n_e",
                    "path": "${workspaceFolder}/packages/client"
                }
            ]
        }
    ]
}

Now the break point within VS Code is a red filled circle and the code correctly breaks on it.

You can do the same in the Firefox dev tools – I actually think I prefer those dev tools for debugging – but then you’re separated from the code.

Setting up Chromium to connect

Now we should be able to do the same for Chrome.

My linux setup doesn’t use regular Chrome, but flatpak Chromium instead. So the second configuration below is much easier.

Note: I found the ${userHome} variable from https://code.visualstudio.com/docs/editor/variables-reference

Similar to Firefox when I had to set a pathMappings config, for Chrome its easier because you just set the webRoot to the packages/client directory. This should work for Firefox too – but doesn’t :woman_shrugging: :woman_facepalming:

{
    "version": "0.2.0",
    "configurations": [
        // This is runtimeExecutable is mildly crazy because of flatpak
        // Normal chrome installs won't need runtimeExecutable
        {
            "type": "chrome", // must be chrome
            "runtimeExecutable": "${userHome}/.local/share/flatpak/app/org.chromium.Chromium/current/active/export/bin/org.chromium.Chromium",
            "request": "launch",
            "name": "Next: Chromium (flatpak)",
            "url": "http://localhost:3001",
            "webRoot": "${workspaceFolder}/packages/client"
        },
        // Regular Chrome
        {
            "type": "chrome",
            "request": "launch",
            "name": "Next: Chrome",
            "url": "http://localhost:3001",
            "webRoot": "${workspaceFolder}/packages/client"
        }
    ]
}

Debug console

Once you have a debug session running, you can access the tab ‘Debug Console’ in the output panel (the same panel as the terminal).

This then gives you what seems to be a perfect console session as you get within a browser.

When you hit a breakpoint you can refer to the locally defined variables and inspect them.