Debugging not working well in Webpack Branch

[masaanli]

Please provide us with the following information:

1. OS? Windows 7, 8 or 10. Linux (which distribution). Mac OSX (Yosemite? El Capitan?)
   Windows 10
2. Versions. Please run ng --version. If there's nothing outputted, please run
   in a Terminal: node --version and paste the result here:
   Beta 10 (webpack / master branch)
3. Repro steps. Was this an app that wasn't created using the CLI? What change did you

   do on your code? etc.

4. The log given by the failure. Normally this include a stack trace and some

   more information.

5. Mention any other details that might be useful.

---

Thanks! We'll be in touch soon.

The debugging isnt working anymore in firefox, chrome or edge.

When I put a breakpoint nothing happens.
When I put a debugger command, it's debugging at strange lines. not where I put the debugger command.

[sirajc]

Some issue on Chrome dev tools side, AFAIK

[masaanli]

@sirajc It's also not working in Firefox for me.
It isn't very easy to work with now hehe;)
With beta 10 from NPM (SystemJS) It was working previous week ;)

[intellix]

I've noticed this actually. If I place a breakpoint inside a mapped TS file, the breakpoint will move up the file about 10-20 lines above and obviously not work. It seems the maps aren't quite correctly generated

[jmc265]

I believe this is a Typescript-mapping problem only. Mapping onto Javascript files (e.g. node dependencies) work fine.

[sirajc]

@TheLarkInn Can you have a look please

[iamyojimbo]

I have also noticed that console errors point to lines far from where the actual error occurred

[masaanli]

Tried to update to the latest Angular CLI Beta 11 Webpack, (NPM) but not worked.

[Namek]

Actually, for me it's sometimes not working properly even before upgrading to webpack (using PhpStorm)

[masaanli]

@Namek Do you mean the Webpack Branch or just the Masterbranch where Webpack is inside?

[masaanli]

I just looked again at this issue and to be more specific; I'm having the same problem on Firefox and Internet Explorer.

@TheLarkInn got some progress on this one?

[Namek]

Yesterday I didn't even touch anything related to webpack in this project. Maybe my webstorm is broken.

[abner]

Actually the problem is being caused by the sourcemap-istanbul-instrumenter-loader which was setup to always instruments the typescript app code in the webpack-build-test.js. Would be better to have a task specific for coverage where the instrumentation would take place. The test tasks will run without instrumentation so we could debug it.

[TheLarkInn]

We did just cut a new release on the webpack tag this morning with improved coverage settings. Would you mind just double checking if mappings work on prod and dev.

[masaanli]

@TheLarkInn going to check it today!

[abner]

The issue isn't the coverage itself. Coverage is OK in master branch. The problem is the instrumented code, when you debug the tests on karma http://localhost:9876/debug.html. All the application code will look like this:

If i just comment out this part of node_modules/angular-cli/addon/ng2/models/webpack-build-test.jswebpack-build-test.js:

    //   postLoaders: [
    //     {
    //       test: /\.(js|ts)$/, loader: 'sourcemap-istanbul-instrumenter-loader',
    //       exclude: [
    //         /\.(e2e|spec)\.ts$/,
    //         /node_modules/
    //       ],
    //       query: { 'force-sourcemap': true }
    //     }
    //   ]
    // },

And run karma again, so i will be capable of debug the code:

But obviouslly i won't have any coverage data :

My proposal is to have two different tasks:

• ng test which will allow run the tests without coverage allowing to debug the application source code;
• ng test-coverage, which will run tests and generate the coverage reports;

I would try make this changes and submit a merge request.

[masaanli]

Maybe the Karma fixed the problem?

But my problem was debugging of just the Source Codes. like app.component.ts etc. etc.

This evening im gonna test it.

[TheLarkInn]

So in test you actually get the sourcemaps for your spec files. So set a breakpoint and you will see those correctly.

[TheLarkInn]

We're still investigating sourcemaps on prod and dev modes though.

[masaanli]

@TheLarkInn Nice to hear that, hopefully we find a quick solution for it! :) Now only can console.log hehe

[TheLarkInn]

So we will have to change these to source-map for now which is ok. This comes with the expense of webpack generating accurate sourcemaps that chrome and firefox won't flake out on (which we [as in the webpack org] is looking into). This comes at the expense of a slightly slower dev env build. But since this is in memory-fs when being ng serve'd it may not even be noticeable.

[TheLarkInn]

You can see more information about how webpack processes sourcemaps are configured here and what the tradeoffs are

[masaanli]

@TheLarkInn thanks, but I can not find the webpack configuration file or the place where to create it?

Can't we release maybe a beta 11 webpack.3 otherwise 👍

[TheLarkInn]

Using a webpack config is only one of may ways to use webpack. It also can be invoked through node using the webpack nodeAPI which we do

[masaanli]

@TheLarkInn sorry for me being an asshole, but I'm new to Webpack. Need some guide on this how to acchieve applying this setting, so debugging is working. Sorry.

[abner]

if we add an arg --debug on ng test tasks we could conditionally not add the instrumenter plugin and not generate the coverage reports (because without the instrumenter the coverage info isn't generated).
This way we would debug on tests also!

[EricBichara]

Is this issue back in beta 18? I created a new project this morning (ng new testproject) and changed only the following code in app.component.ts

import {Component, OnInit} from '@angular/core';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.css']
})
export class AppComponent extends OnInit {
  ngOnInit(): void {
    this.dosomething();
  }

  title = 'app works!';

  dosomething() {
    this.title = "trying to do something";
    this.title = "trying to do something else";
  }
}

In chrome dev tools, breakpoint doesn't seem to match the scope

I've also tested in my other projects which i've updated to beta.18 with the same issue.

ng --version:
angular-cli: 1.0.0-beta.18
node: 6.8.1
os: darwin x64

running:
Npm: 4.0.0
OSX: 10.12.1
Chrome: 54.0.2840.71

[sherwopj]

Happening for me too. Source maps seem to be out by only a few lines, so breakpoints are out too (ridiculous workaround: surround breakpoint with lots of superfluous lines)

angular-cli: 1.0.0-beta.18
node: 6.7.0
os: win32 x64

NPM: 3.10.8
OS: Windows 10 x64
Chrome: 54.0.2840.71 m (64-bit)

[brendanalexdr]

I am getting this debug/mapping mal-config problem too (same as @sherwopj). The debugging was working fine for a while, but after my app got to a critical mass (like around 20 components) it has started to get wonkie: breakpoints won't hit, or impossible to set breakpoint (off by x number of lines)

[fcrocce]

@nukuuk was it working fine with beta18?
We just migrated our app to use angular-cli and are suffering with this annoying issue. I tried downgrading to beta17 but other errors arose

[brendanalexdr]

@fcrocce it was working ok with beta18 for a while, until my app reached a critical mass of components (around 25), then debugging got wonky

[fcrocce]

reverting to beta17 did the trick for me

[ugacode]

instead of reverting you could use this patchy fix from issue #2811 :
Edit node_modules/angular-cli/models/webpack-build-development.js
and change cheap-module-source-map to source-map

[filipesilva]

The issue was back on beta18, fixed on beta19-3 in #2857.

[rightisleft]

I'm still seeing this

➜ web git:(master) ✗ ng -v
angular-cli: 1.0.0-beta.19-3
node: 6.7.0
os: darwin x64

[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.}