Visual Studio Code debugging chrome, Breakpoints wont hit

Question

I have a Angular2/typescript app I am developing in VSCode. I use Gulp to build the typescript files and gulp-sourcemap to create map files. Attaching/launching chrome works well after some tinkering with the chrome debug extension for VSCode, but I cannot get the breakpoints to hit. I run the website with "dnx web", but I don't think that should matter.

My folder structure is like this:

project/wwwroot/index.html
project/wwwroot/app/myfile.js
project/wwwroot/app/myfile.js.map
project/scripts/myfile.ts

My launch.json looks like this:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Launch",
      "type": "chrome",
      "request": "launch",
      "url": "http://localhost:8001/portfolios",
      "runtimeArgs": [
          "--new-window", //Open in new window
          "--user-data-dir=C:/temp/", 
          "--remote-debugging-port=9222" 
      ],
      "webRoot": "${workspaceRoot}/wwwroot", 
      "sourceMaps": true
    }
  ]
}

and my gulp build task looks like this:

gulp.task('ts', function (done) {
  var files = gulp.src(tsToMove)
    .pipe(sourcemaps.init())
    .pipe(ts(tsConfig), undefined, ts.reporter.fullReporter());
    return files.js.pipe(sourcemaps.write(".",{sourceRoot: '../scripts'}))
    .pipe(gulp.dest('scripts'));
})

I have verified that maps files are generated and stored in the same folder as the js files. when building.

Thanks for any hints.

Implicit

Possible duplicate of How to Get Full JavaScript/TypeScript Debugging in Chrome with Visual Studio (Like IE) – Kuo

Visual studio Code is not Visual studio. – Implicit

Try sourceRoot: '../../scripts'. – Fennel

Just a follow up: I ended up using the debugger in Chrome instead. Works all right. No problem with the .map files there. I can see the typescript source and debug through it. – Implicit

Host of reasons. I had to uninstall inbuilt javascript debugger and install the nightly chrome debugger. – Bazooka

Answer 1

Setting the workspace location to the location of my typescript files, and not my build files, worked for me.

Unverified Breakpoint (my compiled file location)

"webRoot": "${workspaceRoot}/build/client"

Working Breakpoint (my ts file location)

"webRoot": "${workspaceRoot}/client"

I feel I should mention that I am using the Debugger for Chrome extension

Enthusiastic

Thank you :) I'm running a workspace with multiple app and library projects and couldn't get most of my breakpoints to hit, they were considered unverified breakpoints. I hadn't noticed this "webRoot" setting in the launch.json. Just needed to set that to the folder of the start-up app I was serving at any given time, now debugging works perfectly even into the library projects' breakpoints. – Bid

If you're confused what path to add, just use Process Monitor from Sysinternals and filter on your source files (e.g. .ts) and not found errors. This'll show you the path VSCode is trying to resolve your source files from. – Alehouse

Answer 2

So I've been messing with this for hours and finally got it working: RVCA18 was right on with his answer:

You need to make sure that webRoot is set correctly, and correctly will depend on where you are running dnx from. If from your 'project' folder, then that's your actual webRoot.

You can also use your sourcemap file. If you open the file, it has a structure something like this: {"version":3,"sources":[],"names":[],"sourcesContent":[]}

Find the sources prop which is an array of all of your source files. For example, if I search for one of my class names, I find the source to be something like: "webpack:///./app/components/TargetCard.js". I am using webpack and have a dir structure like below (simplified):

main
  app
  dist

which means that my webRoot as far as VSCode is concerned should equate to the dir one level above 'app', or 'main'. This is also where I run webpack from, so it makes sense. If I open the 'main' folder in VSCode, then my ${workspaceRoot} will also be 'main', so to have the debugger find my files I should set webRoot to simply be ${workspaceRoot}.

Tansy

Answer 3

If you are using the debugger for chrome extension I would check that you are running chrome with remote debugging? I was able to get mine working after I started running chrome with remote debugging. from https://code.visualstudio.com/blogs/2016/02/23/introducing-chrome-debugger-for-vs-code

For now, Chrome needs to be started with remote debugging enabled, and only supports one concurrent connection. This means if you open up DevTools inside Chrome, the connection to VS Code will get terminated by Chrome. This is slightly annoying, and we hope this issue will be fixed sometime soon.

To do this i have a batch file that opens chrome with this command.

start /d  "C:\Program Files (x86)\Google\Chrome\Application"  chrome.exe --remote-debugging-port=9222

Grosso

this is just needed for request:'attach', if you're using request:'launch' a new instance will launch with remote debugging already enabled. – Tansy

Answer 4

I totally agree with RVCA18. It's about the webRoot Setting that was wrong. I had VS-Code ${workspaceRoot} pointing to a subfolder (just because I opened the project like that and had no script in the top-level folder). Since the index.html that is launched is in the top level folder I had to set the following Option in launch.json

"webRoot": "${workspaceRoot}/.."

Defense

Answer 5

For me, the problem occured in Visual Studio Code, using addons "Debugger for Chrome" with "Live Server".

I got it to work with the following settings:

Live Server's settings.json:

"liveServer.settings.AdvanceCustomBrowserCmdLine": "chrome --user-data-dir=C:/tmp --remote-debugging-port=9222",

launch.json:

"configurations": [
    {
        "name": "Attach to Chrome",
        "port": 9222,
        "request": "attach",
        "type": "pwa-chrome",
        "url": "http://127.0.0.1:5500/${relativeFile}",
        "sourceMaps": true,
        "webRoot": "${workspaceFolder}"
    },

Derick