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:

• inside the DA in "launch" or "attach" when the launch config is available. The output of the verification could be send to the debug console in text form and we could either treat problems as fatal and abort debugging or as informative and continue debugging. The verification could use the ".scripts" tool and verify the paths in its output and only show the errors.
• inside the node-debug extension: here we could verify the launch config and the source maps in the 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.
• inside a separate extension. This approach could be useful for any debugger that uses sourceMaps. But since launch configs are not standardized, it is difficult to find and interpret the relevant attributes correctly.

@roblourens what do you think?

/cc @dbaeumer