Debugging in VS Code using Debugger for Chrome extension of the project generated by CLI 1.7.3 not working properly.

[bardr]

Background

After some break time with Angular I came back to it and needed to create frontend for my project. I wanted to start with the latest version so, I updated the CLI, generate new project and started it, to see if everything working properly. It worked, great. Next I added a launch.json with base Launch Chrome against localhost configuration. Afterwards I served app and started debugging to see if it works. And that's why I'm here, because debugging behaves weird. My breakpoint was moved few lines away, and when breakpoint was hit, VS Code opens read-only file with Webpack comment on the end of the file. Breakpoints (and whole debugging process) live their own lives 😀. With CLI 1.4.3 (had this version before update to 1.7.3) everything works as it should. Details below.

Versions

I tested it on macOS Sierra 10.12.6, Windows 10 Pro and ArchLinux using different Node versions ( 8.4.0, 8.6.0, 9.9.0 ) on each system mentioned before and with CLI 1.4.3 everything works like a charm, in opposite to CLI 1.7.3. NPM version: 5.6.0.

Repro steps

• install latest CLI (1.7.3) using npm install -g @angular/cli
• generate new project using ng new frontend
• add launch.json with default Launch Chrome against localhost configuration

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "chrome",
      "request": "launch",
      "name": "Launch Chrome against localhost",
      "url": "http://localhost:4200",
      "webRoot": "${workspaceFolder}"
    }
  ]
}

• add test funtion in app.component.ts

  public test() {
    alert('test');
  }

• add click event in app.component.html to any a tag:
  <a target="_blank" rel="noopener" (click)="test()">Tour of Heroes</a>
• place breakpoint in test() function on alert('test');
• start app using ng serve
• start debugging with configuration mentioned above
• run the application to the breakpoint (click on the Tour of Heroes text if you followed steps)

Observed behavior

Debugging behaves weird. It does not work as it should.

Desired behavior

Debugging should work as using version 1.4.3 which, "just works".

Other details

Command used to install CLI 1.4.3 after deleting 1.7.3 version:
npm install -g @angular/cli@1.4.3 @angular-devkit/core@0.0.29 @angular-devkit/schematics@0.0.34 (sudo on ArchLinux).

[craigsh]

Same frustrating problem here. Downgrading to 1.6.8 seems to fix things.

[ghiscoding]

I had the same problem too, and I had to modify my launch.json with the following and it started working again

{
      "type": "chrome",
      "request": "launch",
      "name": "Chrome",
      "url": "http://localhost:4200",
      "webRoot": "${workspaceFolder}/app/src",
      "sourceMapPathOverrides": {
        "webpack:///./src/*": "${webRoot}/*"
      }
},

I basically had to change the webRoot and sourceMapPathOverrides and it works again. I'm not sure if this is or will be included when creating a new App (I didn't try), but I leave it here to help others and remove frustration. I also can't live without the debugger.

For more info on how to find the WebPack sourceMap, you can read VSCode Chrome Debug - SourceMap

EDIT
Actually that might not be enough, the breakpoints do work but it opens the sourcemap in readonly mode. Not exactly what I was expecting. If anyone has a better solution please let us know

[bardr]

@ghiscoding Yeah, this was related to sourcemaps. I thought about it but I didn't know how to fix it because I had never faced such a problem. Stupid of me.

This launch.json works:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "chrome",
      "request": "launch",
      "name": "Launch Chrome against localhost",
      "url": "http://localhost:4200",
      "webRoot": "${workspaceFolder}",
      "sourceMapPathOverrides": {
        "webpack:/*": "${webRoot}/*"
      }
    }
  ]
}

For more details - see this comment.

[craigsh]

@bardr Thanks - this now works for me with the updated launch config.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}