JavaScript debugger desyncs with hot module reloading

[andrew0catm]

• VS Code Version: 1.81.0
• OS Version: win8
• Node: 16.19, 18.17

Steps to Reproduce:

1. Create a new angular project
2. Create a launch json file for setting the chrome debugger
3. Start the browser, do a change in you editor, add a new line, add a breakpoint, save it(you might need to repeat this step for 2-3 times but usually reproduces after the first save)
4. After the file is saved and the browser refreshes you will observe that your breakpoint will not hit anymore, seems to be a caching issue, after the browser will be restarted then the breakpoint will hit, the dev tools are showing the correct source code.

This worked before doing the 2 august 2023 update...

[VSCodeTriageBot]

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.81.0. Please try upgrading to the latest version and checking whether this issue remains.

Happy Coding!

[andrew0catm]

Because of the 1.81 update it doesn't work :(

[ooooo84]

VS Code version: 1.81.0, actually I never let it work before (since 1.7x).

Same issue for React app, React version: 16.8 and 17.0 + JS + WebPack. When I try to add more breakpoint after running the debug process, it always goes to the compiled source. The only way to make it work is to re-run the project, but we have a huge project, it needs about 20-25 mins to run. So that, I have to use WebStorm to debug the code.

[middiu]

same problem here with React. Everything was working fine before the latest update.

[connor4312]

/jsDebugLogs

[VSCodeTriageBot]

Please collect trace logs using the following instructions:

If you're able to, add "trace": true to your launch.json and reproduce the issue. The location of the log file on your disk will be written to the Debug Console. Share that with us.

⚠️ This log file will not contain source code, but will contain file paths. You can drop it into https://microsoft.github.io/vscode-pwa-analyzer/index.html to see what it contains. If you'd rather not share the log publicly, you can email it to connor@xbox.com

[middiu]

this is my log trace: vscode-debugadapter-affae410.json.gz

and this is the current env: Version: 1.82.2 (user setup) Commit: abd2f3db4bdb28f9e95536dfa84d8479f1eb312d Date: 2023-09-14T05:55:25.390Z Electron: 25.8.1 ElectronBuildId: 23779380 Chromium: 114.0.5735.289 Node.js: 18.15.0 V8: 11.4.183.29-electron.0 OS: Windows_NT x64 10.0.19044

[middiu]

Tested on my Mac on a different ReactJS project and got the same problem, after few app changes the breakpoint is not hit:

Version: 1.82.2 Commit: abd2f3db4bdb28f9e95536dfa84d8479f1eb312d Date: 2023-09-14T05:59:47.790Z Electron: 25.8.1 ElectronBuildId: 23779380 Chromium: 114.0.5735.289 Node.js: 18.15.0 V8: 11.4.183.29-electron.0 OS: Darwin x64 22.6.0

[jackpunt]

When I updated VSCode 1.81, the debugger loses breakpoints (not sure what was running before, pro'ly 1.7x something)

Oh! the breakpoints seem to be better on 1.82; But still they are off by a line or two, which is sad and confusing. (Oh! they get more and more off with every edit!?)

The breakpoints show in the VScode margin as Ok/Red, but the 'break' is not at that point in actual code; although page has saved and reloaded, etc. The only reliable way to resync is to restart the debugger / ng serve

Possibly a clue: in the VSCode "Debug Console", the right-side links to the 'console.log' invocation are also mis-directed, sometimes waaay off (saying "source.ts :38" when the source code and chrome debugger agree it is from "source.ts :157")

Version: 1.82.2 Commit: abd2f3db4bdb28f9e95536dfa84d8479f1eb312d Date: 2023-09-14T05:59:47.790Z Electron: 25.8.1 ElectronBuildId: 23779380 Chromium: 114.0.5735.289 Node.js: 18.15.0 V8: 11.4.183.29-electron.0 OS: Darwin x64 22.6.0

[connor4312]

But still they are off by a line or two, which is sad and confusing

This is likely to be an issue in your build setup/tooling.

[jackpunt]

"This is likely to be an issue in your build setup/tooling."

Hmm, the only build setup/tooling I have is angular and vscode. And it was rock solid until upgrading to 1.81 and now 1.82.... ( and angular has not changed)

When freshly compiled, it works, but with each recompile (ng serve watching) it get progessively worse.

[middiu]

But still they are off by a line or two, which is sad and confusing

This is likely to be an issue in your build setup/tooling.

I have a different build setup/toolin (React App - CRA) and I'm facing the same issue. And I can confirm that until a couple of versions ago everything was working perfectly.

[jackpunt]

In re tooling: I have one project with Angular 14.1 and one with Angular 15.2; both show the problem. Note: the code is typescript, so there is that additional layer of translation when ng/webpack recompiles.

From adding code and then undoing the source (with ng serve recompiling/webpacking/browserloading on each save) We see that when undo back to the 'original' source (when debugger first triggered 'ng serve') the breakpoints align. But when running with edited code, it seems that the editor is not using the correct source map.

That is:

1. save code, start debugger --> ng serve --> browser opens
2. breakpoints work and aligned with source in vscode editor
3. edit source (for ex, adding lines of code), save --> ng serve recompiles/webpacks --> brower refreshes
4. breakpoints not aligned; remove/re-add breakpoint; when invoked editor shows 'caret' at wrong place (for ex in comments, or before/after point of actual code execution)
   • To make it clear/obvious: add lines of: console.log('your content here');
   • Note that the reported location of the console log statement in the VSCode DEBUG CONSOLE is incorrect .
   • Also fun: // comment those console.log statements; set a breakpoint nearby; the breakpoint shows in the comment.
5. undo in source code (to original state in '1' above), save --> ng serve recompiles/webpacks --> browser refreshed
6. now/again breakpoints align.

The implication is that the VScode debugger is not using the updated source maps when ng/webpack recompiles.

[jackpunt]

What is the status here? Is this being investigated? Is it reproducible on your end? Can you find any [recent] mods to the breakpoint/code-mapping code that may be relevant?

Let us know how we can help.

(as things stand, the in-VScode debugger for chrome/typescript/webpack is nearly useless)

[middiu]

What is the status here?

Is this being investigated?

Is it reproducible on your end?

Can you find any [recent] mods to the breakpoint/code-mapping code that may be relevant?

Let us know how we can help.

(as things stand, the in-VScode debugger for chrome/typescript/webpack is nearly useless)

Agree, I have to stop and restart the debugging every 10 mins, it's really annoying

[connor4312]

This issue is hard to track down, because this is the process:

• You save your file, webpack HMR's it and sends the new file down. Now two things happen in parallel:

  (a) the debugger sees the new file come it. It applies the breakpoint location is knows about, then allows the browser to run the file. (b) VS Code sees the file is saved, and tells the debugger to remove the breakpoint on the old line, and puts it on the new line

• If (b) happens before (a), everything is good. But if (a) happens before (b), the breakpoint will initially be on the old location and it may be misplaced or not placed at all.

---

the in-VScode debugger for chrome/typescript/webpack is nearly useless

This issue pertains solely to HMR behavior with webpack, and such issues would be cleared on a manual refresh of the page. If you're hitting a different problem, please open a separate issue with more information.

Agree, I have to stop and restart the debugging every 10 mins, it's really annoying

It sounds like you're hitting a different issue if you have to start and stop debugging.

[jackpunt]

It sounds like you're hitting a different issue if you have to start and stop debugging.

Thanks for the feedback!

Alternatively: It sounds like the issue the you diagnosed is different from the one we are complaining about.

For me, reloading the page solves the problem of "links in the PROBLEMS" but does not** fix breakpoints. Restarting the 'debugger' starts a new 'ng serve' and that re-syncs the breakpoint/code-map.

. ** Is anyone else complaining that the PROBLEM output initially has links to the compiled code, rather than the source code? only after clicking one of those does the link to editable source appear in the PROBLEMS.

. . Also: what middiu says below: killing the browser is what forces to restart the debugger.

[middiu]

It sounds like you're hitting a different issue if you have to start and stop debugging.

let me reprashe it: I need to close and re-open the browser so have the new breakpoint line working.

Of course when I close the browser the debugger stops. Hopefully yhis makes more sense

[jackpunt]

Seemed to be working again! [ I stand corrected... after line insertions breakpoints in the wrong place]

Version: 1.82.3 Commit: fdb98833154679dbaa7af67a5a29fe19e55c2b73 Date: 2023-10-02T11:06:17.496Z Electron: 25.8.1 ElectronBuildId: 24153832 Chromium: 114.0.5735.289 Node.js: 18.15.0 V8: 11.4.183.29-electron.0 OS: Darwin x64 22.6.0

[connor4312]

VS Code 1.83 was just released that improves behaviors of breakpoints across refreshes, you may see better behavior there (though I have not specifically validated to see if it fixes the issue you describe)

[dZbear]

Facing the same issue with 1.83 (breakpoint not being mapped to correct lines after code insertion)

Version: 1.83.0 (user setup) Commit: e7e037083ff4455cf320e344325dacb480062c3c Date: 2023-10-03T16:12:16.321Z Electron: 25.8.4 ElectronBuildId: 24154031 Chromium: 114.0.5735.289 Node.js: 18.15.0 V8: 11.4.183.29-electron.0 OS: Windows_NT x64 10.0.19045

Angular 15 project, default setup

edit: I just tested VS Code 1.79.2 and the behavior is correct in this one.

[middiu]

Yes same, 1.83 doesn't solve the problem

[hammeronthenet]

For me the same, 1.83.1 doesn't solve the problem.

Angular 13 / node 16.10 project: when I add one line (or more) the breakpoint stopped to work and adding them in the new line just not worked as descripted above.

It happens just one day to another, no way to revert.

EDIT: the same happens to other two collegues (one with Ubuntu, the other with MacOs, i'm on Windows) on a totally different project ( not Angular, but nodeJs with Typescript).

[hammeronthenet]

Hi all, nothing new about that? It's really frustrating to work on a big project with a lot of maths and be unable to debug without restarting the debugger (and then the browser) every time.

[connor4312]

the same happens to other two collegues (one with Ubuntu, the other with MacOs, i'm on Windows) on a totally different project ( not Angular, but nodeJs with Typescript).

This sounds unrelated to this issue, as this pertains to Webpack hot module reloading which does not operate in Node.js. They should file a new issue and provide information using the instructions in the issue template.

[connor4312]

For people hitting the "breakpoints are bad until the debugger restarts" issue, please follow https://github.com/microsoft/vscode-js-debug/issues/1803. A fix will be available tonight.

[zxanderh]

@connor4312 Thank you so much! This has been driving me crazy.

For those finding this post before the next official release, you can get the fix now by installing the nightly: https://github.com/microsoft/vscode-js-debug/tree/main#nightly-extension

[nicorac]

For people hitting the "breakpoints are bad until the debugger restarts" issue, please follow microsoft/vscode-js-debug#1803. A fix will be available tonight.

I'm still experiencing this bug, tried both bundled and nightly JS Debugger extension. It broke starting from VSCode 1.81.1

Current versions:

• VSCode: 1.83.1
• JavaScript Debugger (Nightly): v2023.11.117
• Angular: 16.2.4

The bug happens in multiple configurations:

1. Single Angular 16 application
2. Monorepo NX fullstack application (Nest.JS backend and Angular 16 Frontend)
3. Android Ionic WebApp (Angular 16)

The most easily reproducible is 1), so I took a debug log from it (see below).

1) Single Angular app

To reproduce the bug:

• create a blank Angular app with ng new test
• open VSCode in the created folder
• set a breakpoint to the only one created component
• launch the app (F5 --> ng serve)... the breakpoint hits
• now edit the file (i.e. add some empty lines before the line with the breakpoint
• the line with breakpoint moves down together with the red breakpoint circle
• save the file, Angular rebuilds, Chrome reloads the page, the red breakpoint circle goes out-of-sync (up to an empty line)
• source file and map are correct if opened in Chrome DevTools (so it seems VSCode is guilty...)

The only way I've found to resync source maps is:

• close Chrome (note that ng serve task keeps running in the background)
• relaunch Chrome with F5 (ng serve task is already running, so Angular won't recompile anything...)
• now breakpoints are synced with .ts sources

This is the captured logfile: breakpoint hit, source edit, save, auto recompile, same breakpoint not hit. vscode-debugadapter-467f2aad.json.gz

2) Monorepo NX fullstack application

The issue here is the same, but it affects only Frontend changes (as like above).

Editing backend .ts files causes a rebuild+reload of Nest.JS (Node) app and breakpoints remain in sync.

3) Android Ionic WebApp (Angular 16)

NOTE: To debug on a real Android device I use the "Android WebView Debugging" extension (mpotthoff.vscode-android-webview-debug).

Same issue: changing+saving a source file causes the breakpoint to go out-of-sync. I need to disconnect from chrome and reconnect (ng serve still running) to resync.

---

I'm ready to give further info and do additional tests, if needed.

[connor4312]

In the log you captured, the compiled file was unchanged (by adding blank lines.) The fix I added made sourcemaps invalidate whenever the hash of the compiled file changed. While the raw case of adding/removing code that doesn't change compiled code can still unfortunately lead to cases where the sourcemap is held onto for longer than ideal, in practice development will involve making substantiative changes that will change the hash.

[connor4312]

I'm going to lock this issue since this has repeatedly strayed far off from the issue the original poster mentioned, perhaps due to its generic title and thus ease of discovery via search. If anyone has continued or separate problems, please create new issues for them https://github.com/microsoft/vscode-js-debug/issues/new/choose