Support Live Reloading Scenarios

[digeff]

We'd like VS Code and the Node Debugger to support Live Reloading Scenarios. The current behavior is preventing React-Native users from having a good experience: microsoft/vscode-react-native#74

Currently it's not supported so modifying breakpoints while the program is running can have weird results (Breakpoints set in one line, appear in another line, or get deleted completely).

Things that we'd like to be supported are:

• Be able to edit a file in memory, and set a brekpoint before saving the file, so if there is any source map associated at all with this file at all, it'll map to the wrong thing, so VS Code would need to Remember the line where the breakpoint was set, and wait until the proper source map was loaded before actually setting the breakpoint.
• Be able to edit a file, save it, and set breakpoints before the recompilation process is finished, so initially it'll be associated with the wrong source map.
• The red and greyed out stop signs for the breakpoints should correctly indicate if the breakpoints were successfully installed.
• Editing a source file with breakpoints should result in intuitive results when adding lines before, or after the breakpoints, or even on the same line.

[weinand]

related issues:

• make source maps async: Make source map handling asynchronous #8162
• update breakpoints after save: VSCode should only reset breakpoints after save when already debugging #8077
• meteor: Source map don't refresh after source change/save & node restart. Attaching/re-attaching to Meteor.js server (meteor debug) #7117
• SystemJS: Feature request : add in code 'debugger;' to breakpoints panel for .ts and .js files #4492
• babel-register: Debugging with babel-register + NodeJs does not work #5728

[sivaraman-gmail-com]

Will implementation of this also allow for live javascript editing when debugging a web app via the Chrome debugger extension? This is a key feature missing compared to IDEs such as WebStorm and debugging from within Chrome itself.

[auchenberg]

@weinand @roblourens We seem to have closed the blocking issues for this scenario, which means we should be good to have debuggers implementing file-watching-like functionality.

We should start by prototyping this in the Chrome family debuggers, which would light up this for Node, Chrome, Edge and others. See https://github.com/Microsoft/vscode-chrome-debug/issues/216

[nojvek]

Will there be any config to place in a hook call? E.g after live edit is called, a command defined in debugger target config is automatically executed.

This opens up great possibilities for hot reloading and test driven development.

Since this will work with async sourcemaps and file watchers I think it will be a lot more powerful than the live edit scenario chrome gives out of the box.

[weinand]

A typical live edit scenario.

Preparation:

• set autosave to off
• have a TypeScript based transpilation setup

Scenario "edit TypeScript source while being stopped on a breakpoint":

• set breakpoint in some TypeScript source
• start debugging
• make program hit breakpoint, e.g. load a url in a browser
• single step a little in the TypeScript source until you spot some broken code
• fix source code in editor
• breakpoints are marked as unverified (grey) because underlying source has changed
• save source
• breakpoints will show up as verified again
• if current location is in the scope of the edited range, location jumps to the beginning of that range (like "restart frame" action)
• you can single step through the fixed code
• if everything works fine continue program execution

Behind the scenes:

• saving the TypeScript source triggers a build watcher to transpile the TypeScript to JavaScript and create a corresponding source map (this is independent from the debugger's live edit support)
• a file watcher in the debug adapter detects the changes to both files
• the path to the JavaScript file matches the path to a loaded script which triggers this:
  • the DA replaces the loaded script with the new contents
  • if this is successful it invalidates any cached source maps referring to the JavaScript
  • if current location is in the scope of the edited range, issue a "restart frame"
  • request a "reapply" for all breakpoints for the affected file(s). As a side effect breakpoints are reverified.

Misc:

• auto-save might might result in file modification events at times when the source is incomplete or syntactically incorrect and won't compile. This might confuse the runtime. Better: rely on an explicit build-done event before reloading JavaScript in the runtime.
• the VS Code file watcher could be used to watch for file modifications and report them to the debug adapter
• there are more complex transpilation setups that are difficult to support (see https://github.com/Microsoft/vscode-chrome-debug/issues/216#issuecomment-264535388)

Conclusion:

• most of the remaining work has to take place in the debug adapter. The generic VS Code debugger UI is already prepared for this.
• using the file watcher from VS Code could simplify the implementation of the debug adapter (and reduce the number of parallel running file watchers). This require a protocol addition.
• There is no mechanism that a debug adapter can request a "reapply" for all breakpoints for a given file. But a debug adapter could do this behind the scenes and just emit breakpoint events to update the validation status in the UI.

Next Steps:

• validate this analysis and approach in node-debug by using the changeLiveRequest_ and restartFrameRequest_.

[auchenberg]

@weinand For the the DA replaces the loaded script with the new contents step you have outlined. Are you referring to having the DA using API's such as Node/Chromes debugger.setScriptSource?

The file-watcher in VS/DA should be togglable, as many developers for front-end scenarios already relies on WebPack HMR or similar, which enables https://medium.com/@auchenberg/live-edit-and-debug-your-react-apps-directly-from-vs-code-without-leaving-the-editor-3da489ed905f today.

[weinand]

@auchenberg yes, the 'node2' DA would use Node/Chrome's debugger.setScriptSource and node would use changeLiveRequest.

The goal of this analysis was to figure out the likely interaction between VS Code editor/debugger and the DA. How the DA implements Live Edit is an implementation detail of the DA.

The file-watcher in a DA is an implementation detail of the DA and as such is not covered by the DAP. So every DA that uses a file-watcher can provide a flag in its launch config to control it.