angular-cli projects not hitting breakpoints as set

[bigteejay]

I followed the recipe here essentially verbatim (aside from: what I named the app, not installing ng globally so as to not cause conflicts, and using npx to run the generator for a new project.)

However, the breakpoints aren't aligning at all. You can see it captured here...

This is maddening. I spent days trying to sort this out in my actual project (even thought perhaps it was an issue with line endings, so I converted all the line endings to LF/Unix/\n, and still no luck.)

Visual Studio Code
Version 1.22.2
Commit 3aeede733d9a3098f7b4bdc1f66b63b0f48c1ef9
Date 2018-04-12T16:38:45.278Z
Shell 1.7.12
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64 (Win 10)

Node
v9.10.0

Npm
5.6.0

It seems some other folks have been having this probem with VS Code (with other technologies like Vue as well.) I love the idea of VS Code otherwise, just wish it worked consistently! :-( I swear it was working without issue at one point I thought (I haven't updated VS since, not sure what changed.) I even tried grabbing previous commits when I thought it wa working, and still no luck.

Is there any additional info I can collect to help diagnose this?

[bigteejay]

This helped explain why the second window ("read only inlined") opens (somewhat.) I'm still not sure what is causing it to begin with, but now I have a faint notion of what it is as least.

[bigteejay]

I meant to mention too, the breakpoint remains in place through the "launch" of the debug/chrome session. It is only after I refresh the browser (to triger the breakpoint, as instructed in the recipe) that the line of the breakpoint then moves.

[bigteejay]

Chrome version: 66.0.3359.117 (Official Build) (64-bit)

[bigteejay]

Weird, on a whim, I did an npm run build to create dist output folder (thinking it would have the sourcemap files) and then made the following changes to launch.json and tried again.

"webRoot": "${workspaceFolder}/src/app",
"sourceMapPathOverrides": { "webpack:///*": "${webRoot}/dist*" }

The first time I reloaded, the breakpoint worked and stayed in place! I was shocked so I tried it again, changed nothing, but moved the breakpoint down to the next statement (two lines down) and refreshed. This time it moved the breakpoint to the next line and broke in at that statement again instead.

Literally nothing changed but where the breakpoint was!

[bigteejay]

So strange, I literally came back to it this morning and...

1. Thought I still had npm start running in a powershell window
2. Launched a debug session
3. It brought up a page not found
4. I ran npm start in the powershell window
5. While it bundling, I moved the bpx from the second statement in a ctor to the first
6. Launched debug once bundling done
7. Page loaded
8. Refreshed, and it stopped at the first statement as it should!
9. Moved bpx to the second statement
10. Refreshed, and it stopped there as it should!

I am at a total loss as to what could conceivably be causing this.

[bigteejay]

If it matters, I just realized, in step 9 above, I didnt close the "read-only inlined" window, and moved the bpx there instead of in the actual source file (which was also open in a tab to the left.)

Closing that window and changing the bpx in the original file/tab, refresh page, bpx stops at the line after the one I selected in the new tab again..

Should we only be using the "read-only inlined" tab for debugging? There is no way to open it directly that I am aware of.

[bigteejay]

Where does the code that npm run build creates and serves up reside (in memory? on disk somewhere outside the project folder?) npm start doesn't create an output folder (as far as I can tell).

I hoped to check the output produced for any oddities. I can check in ./dist but that must not be what npm start uses to serve things up (as it will do so without a `./dist' present or even being built yet.

[bigteejay]

PS: Discovered that webpack dev runs are in fact in memory.

Not news to the devs I am sure, but in the event that any google their way here and are curious.

[bigteejay]

I am guessing the issues I am experiencing are related to this as well?

[bigteejay]

I saw mention of checking this log file (~/.vscode/extensions/msjsdiag.debugger-for-chrome-<version>/sourceMapPathOverride.txt) for hints as to how the source map generation went, but have not yet tried that (it appears that flag to enable this may no longer be "diagnosticLogging": true as well.)

[bigteejay]

There was this mention of upgrading VSCode's Chrome Debugger extension to 4.2.1, yet mine is already at version 4.3.0 and I continue to experience inconsistent behavior with debugging (lines not matching, or at times the debugger not even catching after reload in VSCode.)

[bigteejay]

Apologies, I just realized this, instead, is probably the most appropriate place to have captured this.

I'll close this and will cotinue there (I imagine admin can reopen this should they deem is necessary.)