Resolve sourcemaps before scripts are loaded, like the Node adapter

[roblourens]

From @roblourens on November 5, 2015 5:44

Example:
Debugger is attached to Chrome. b.js has code like this:

var x = 1;
function f() {
    console.log('test');
}

User sets a breakpoint on the first line, and another inside function f. When b.js is loaded on the page, the first line bp will not be hit. When f() executes, that breakpoint will be hit. The adapter currently waits for b.js to be loaded before setting its breakpoints, so it knows its full path.

The problem is that before b.js is loaded, the adapter doesn't know what its exact url will be. Maybe Chrome is on www.mysite.com and the local file is C:/folderA/folderB/folderC/b.js. We can fix it by introducing another launch config field, like webRoot which the user sets to C:/folderA so the adapter will know that b.js is on www.mysite.com/folderB/folderC/b.js.

Workaround - attach to Chrome, set the breakpoint in b.js, cause b.js to be loaded (but BP is not hit), refresh the page, now when b.js is loaded, the breakpoint should be hit.

Copied from original issue: Microsoft/vscode-chrome-debug#20

[roblourens]

From @danmosemsft on November 9, 2015 2:42

And/or you could store the file->URL mapping after it is established. That way global breakpoints would work the 2nd and subsequent times. If the mapping changes, which is unlikely, the worst case is it doesn't work.
Basically you'd infer and store "webRoot"

[auchenberg]

How does other other DevTools handle this case? We should aim to provide a consistent experience.

[roblourens]

This is maybe more impactful for Node since you can't "refresh the page". Long story short, scripts are not resolved to the version on disk until the script is actually loaded in the runtime, whereas the Node adapter will set breakpoints by path before the script is loaded. This is a lot easier in the Node case but basically impossible for a browser when sourcemaps are involved which is why I abandoned that strategy.

For Node I'll probably have to bring that logic back. Not sure exactly how that will work. And we might have to disable it for Chrome. It's easy to have an outdated version of your code on disk, and webpack-dev-server serving a newer version or something.

I haven't tried it in CDT yet. I assume it persists breakpoints across sessions, remembers that blah.ts:5 will be sourcemapped to whatever.js:7, and sets the breakpoints by url before whatever.js loads.

[auchenberg]

Yeah, I was mostly wondering how we handle it in Edge DevTools, and how other DevTools does it. I can dig into this, if that can help us clarify what the right solution is?

[roblourens]

In any browser, you have to refresh the page to debug global code, (unless you're using the debugger statement). And you have to load the page once, set your breakpoints, and they're persisted for the next time. Then the rebinding on refresh happens on the browser's end.

The difference for node is that in a launch scenario, I think you can start node in debug node, set your breakpoints by url, then tell it to start actually running. And you can't refresh the page, so you have to get it right before scripts load. You can restart the debugging session but we don't save info like that across sessions.

[auchenberg]

I see, got it.