A breakpoint in my Mocha test works when set on the exact same line in one VS Code tab but not in another.
The difference: If the full path appears in the tab, then breakpoints work. (Second item in screenshot.)
But if the filename, without path, appears in the tab header, then breakpoints all become Unverified (gray) during execution.
Repro steps:
How can I avoid this without continually checking which path variant is appearing?
(Here is a GitHub ticket that I opened.)
Any code with breakpoints executed before vscode could attach, will not trigger the breakpoint. To solve this, either restart the debugger after it has initially loaded (keep Chrome open). use .scripts command in Debug console to see the loaded scripts. Make sure the paths of the scripts is correct.
Breakpoint ignored because generated code not found (source map problem?). You’ll have to make sure that your generated source map points to the correct file paths. In your launch.js
Disabled breakpoints are represented by a filled gray circle, whereas a gray hollow circle signals breakpoint that can’t be registered. The latter may also apply if you’re editing the source while your debug sessions without live-editing support are in progress.
Breakpoints may still not trigger on initial load. When you start the debugger which launches Chrome, there is a lag before vscode can attach to Chrome. Any code with breakpoints executed before vscode could attach, will not trigger the breakpoint. To solve this, either restart the debugger after it has initially loaded (keep Chrome open).
Answer (figured out on the GitHub thread):
My workspace path was under a symbolic link (Ubuntu).
VS Code apparently dereferences symbolic links to give Node a path that it can work with, to support breakpoints.
VS Code also shows the file at the correctly referenced path in my workspace folder as I defined it (under the symbolic link).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With