-
Notifications
You must be signed in to change notification settings - Fork 29.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve discoverability of js-debug diagnostic tool #57590
Comments
I think this would have to happen inside the DA, because we would need to verify this after sourcemaps are loaded or downloaded, (they aren't always available through outFiles) and after pathMapping and sourceMapPathOverrides have been applied. Also I think it shouldn't cause debugging to stop. Files can be loaded at any point during the execution of the program, we can't do all of this up front. And there are probably people who have some files that aren't resolved correctly, but they are still debugging successfully, and we shouldn't disturb them too much. There are probably some valid scenarios like when you are debugging and only have part of the project checked out locally. I think that printing a warning could be useful, when a script loads and its sourcemap paths are not resolved to a file on disk. As long as it's not spammy. As a first step, we could add some telemetry for that case - it would be interesting to see how many people are debugging with unresolved sourcemaps. Also, whether breakpoints are actually resolved to locations, I don't think that's covered by telemetry. |
Making it easier to troubleshoot and fix sourcemap issues is the number one thing that VS Code could do to make my work more efficient. I've wasted more time dealing with sourcemaps than any other part of my Node/React app. So help in this area would be very useful! I think a good starting point could be to add a debug console command that provides scriptmap diagnostics that are easier to use than the current Here's some suggestions for requirements for these diagnostics:
Note that most of the sourcemaps issues I run into are caused by libraries, not by app code. There are two basic reasons:
This means that troubleshooting inside VSCode is an important first step, but solving the problem also involves getting lots of library authors to fix their sourcemaps. IMHO the ideal would be a warning inside |
Agreed, if anyone wants to work on this, I would definitely take a PR for this for
I would take a PR for this, of course finding a file at that path doesn't mean the mapping is correct, and not finding a file at that path may or may not be an error. e.g. inline sources may be expected to be used. Or they may be present but the file is expected to be present.
I think it currently shows sourceRoot + source
I don't think this is technically an error but I'm not sure
👍
But this could be a useful separate tool for some people. It sounds like it would make sense as a tool separate from vscode.
Right click to Copy All? (Not a perfect solution though) |
Having similar issues in a setup where I'm using webpack with TS loader to generate server side bundles of node apps with inline source maps. |
@connor js-debug has already something like this, correct? |
Yes, we have a diagnostic tool as of microsoft/vscode-js-debug#260, but currently this is not discoverable. I will use this issue and some of your suggestions for that. |
Is there a js-debug diagnostic tool? I am getting 'unbound breakpoint' when I run the debugger for a react app and I cannot figure out what is wrong. The same configuration worked ok few weeks ago. |
I found Create Diagnostic Information command. Great tool! It would be nice to be better documented. |
I've decided to try out showing a helper prompt when all of these conditions are met:
|
@connor4312 - This looks great! Thanks so much for moving this forward. Some questions: Can this text contain a link to the docs where the user can learn how to do this? Also, other than changing the build tool (which may not be possible in some cases, e.g. non-ejected
In my experience, the most common sourcemap problem I run into is when libraries in The ideal behavior from VSCode (which might not be possible) would be to identify that Is this possible? I'd be happy to help with the extra text required. |
Thanks for the feedback! I'll tweak things. I'm also happy to take PRs, the source code for the breakpoint helper is here. Simple small (p)react app with a handful of heuristics 🙂 |
This is very confusing and I don't understand why I am seeing this notification. All I am doing is debugging integration tests (with success) when running out of sources. So
|
@jrieken do you have (no breakpoints in api tests and) breakpoints set in core that are not hit with the extension host config? That's a known case where the helper can display inappropriately -- if you have a workspace with multiple disjoint configs. |
I found a bug this morning that can cause this to pop up when it shouldn't. Will be better in the next build. |
No, only breakpoints in the API tests, like |
@jrieken are you on nightly or stable? I haven't released a new stable build with the fixes yet. |
idk - whatever ships with insiders |
Okay, yea I see on the notification it's not nightly. I will bump js-debug this afternoon or Monday, at which time this should be fixed. |
Marking verified since it can't really be verified for endgame as it's in an ongoing experiment |
Today I saw another problem with breakpoints not being hit because the sourcemap's
sourceRoot
was wrong (because it was configured incorrectly in the tsconfig.json).The fix was trivial for me, but for a user it is not obvious what the problem is. Hovering over the grey breakpoint just shows a not very informative message "unverified breakpoint".
And not many users are aware of the ".scripts" utility that can be run on the debug console to see the source mappings in detail. And the output of ".scripts" is a bit verbose and does not highlight errors. See this example from node-debug which has a wrong
sourceRoot
entry in the source map of sourceMaps.js:I think we can and should do better!
My proposal:
For obvious reasons we cannot show a warning message when an expected breakpoint is not hit.
But we could do an upfront verification pass over all generated files reachable via the
outFiles
globs and if they have a source map reference at the end we can verify that the source map exists and that contained back reference to the source is points to an existing file.If the verification process sees error, we could show detailed information about the problem.
In order to keep the amount of information small, we could limit the verification to only those source files that actually have breakpoints.
This verification can be implemented in basically three ways:
resolveDebugConfiguration
method which makes it possible to show nicer UI and ask the user whether he wants to continue or abort debugging. Another advantage of doing the verification in the extension code is that the code is shared for both node-debug and node-debug2.@roblourens what do you think?
/cc @dbaeumer
The text was updated successfully, but these errors were encountered: