This week I learned how to get the VS Code Chrome Debugger to work with a web app that I work on which uses webpack. The whole process was pretty straightforward to accomplish, and the VS Code Chrome Debugger is a lot of fun to work with. In a word: cool.

The Process:

Install Debugger for Chrome and reload your workspace

2. Open up the debugger panel: it’s the “no bugs” icon right above the extensions icon, or you can hit CMD + SHIFT + D

3. In theory, or maybe in practice if you’re lucky, you can click the green arrow, Chrome Debugger will generate a launch.json for you, and you can merrily drop breakpoints into your code, no problem. If you are not lucky, there may be a few things to work out before you are on your way

That green arrow.

4. First, there’s this Chrome remote debugging mode funny business mentioned in the readme:

“If Chrome is already running…”

For me, Chrome was already running for two reasons: my webpack config automatically opens my dev server when I start it, and I was currently reading the documentation for this extension.

I thought, no problem, I’ll just set Chrome to have remote debugger enabled all the time. Except, you can’t do that, (if you are on Mac) you have to execute /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 in your terminal, which is exactly how I never want to open Chrome.

Happily, the Chrome Debugger extension solves this issue by launching a separate Chrome instance with remote debugging enabled. So, I had to get used to managing a separate Chrome instance which I always launch via the debugger panel, but it’s a small and worthwhile inconvenience for the payoff.

5. Chrome Debugger needs to know where your files are served from or it won’t know how to stop on your breakpoints.

“Notice me, Debugger!” — Your Breakpoints, probably

Take a gander at this snippet from the Readme:

The webRoot config is in .vscode/launch.json

Set webRoot to the directory that files are served from. My app uses webpack, which means that my local servers are being launched by webpack-dev-server, so I popped over to the webpack-dev-server docs to see where it serves my files from:

After poking around a bit, I found what I was looking for:

By default it will use your current working directory to serve content…

Superb! Chrome Debugger has a variable for that inside of launch.json called ${workspaceFoler} so my config should look like:

{

"type": "chrome",

"request": "launch",

"name": "Launch Chrome against localhost",

"url": "http://localhost:8082", // or whatever port you use

"webRoot": "${workspaceFoler}"

}

Or, at least, that’s what I thought would work. Except, that I had followed the recommendation in the webpack docs for my webpack config and set a context :

Setting a context actually changes the path for webpack-dev-server and by extension Chrome Debugger from just ${workspaceFoler} to the context path, which, for me, was /app (the same as you see in the docs above). So my actual working config is:

{

"type": "chrome",

"request": "attach",

"name": "Attach to Chrome",

"port": 9222,

"webRoot": "${workspaceFolder}/app"

},

{

"type": "chrome",

"request": "launch",

"name": "Launch Chrome against localhost",

"url": "http://localhost:8082",

"webRoot": "${workspaceFolder}/app"

}

I added the attach action as well, which uses the same webRoot config and allows you to attach to an already running session (assuming that the instance of Chrome has remote debugger enabled), which is useful for hopping in and out of debugging sessions.

Success!

Following those steps got me up and running with Chrome Debugger for VS Code and now I am merrily dropping breakpoints right in my editor as if I’m some kind of IntelliJ-using Java developer. I am very 💯 🎉 Excited 🎉 💯 about debugging inside of the editor. It speeds up my process considerably, and reduces some of the mental strain of debugging hard problems. This was definitely a cool thing I learned, and I’m glad to share it.