React-native-windows: Implement Direct Debugging

[kmelmon]

Proposal: Add support for Direct Debugging

Summary

React-native has direct debugging on other platforms. My understanding is this allows you to debug the javascript running directly in-proc rather than out-of-proc over a websocket connection. We don't support this yet in vnext. This issue is tracking adding support.

Motivation

Basic example

Open Questions

[akrantz]

There is some support in vnext for direct debugging. See https://github.com/microsoft/react-native-windows/blob/b7b40b934e7d935166ee827d66ac4f5b469add9b/vnext/ReactWindowsCore/DevSettings.h#L54 The ability to use this depends on the JavaScript engine. I did the work to enable this for ChakraCore.

[mganandraj]

I'm working on getting direct debugging hermes/v8 into RNW. You may assign this to me.

[ahimberg]

uwp.vnext has a UseDirectDebugger setting on ReactInstanceSettings that enables this with the inproc Chakra engine, when that is set you can then attach with visual studio's script debugger.

[harinikmsft]

Is there a button on a developer menu that could make discovering this easier?

[stecrain]

Adding a bit more information here.

Chakra DirectDebugging works-ish in UWP. Setting the UseDirectDebugger flag to true will allow Visual Studio to debug JS executing in Chakra.

This at least means that we don't have a black-box situation when running from a bundle.

Unfortunately Source Maps don't seem to work correctly with Visual Studio. This makes debugging a bit more painful. Debugging the minified is insane, but debugging a non-minified bundle is doable.

Direct Debugging with other JS engines (Hermes / v8 / ChakraCore) is even more painful. The typical pattern is to open a socket and listen for connections on localhost.
Listening for an incoming request on localhost is blocked by the UWP App Container.
This restriction is mentioned in these docs
You can confirm this by looking in the firewall logs (c:\windows\system32\logfiles\firewall) for lines like this

2019-10-10 12:57:11 DROP TCP 127.0.0.1 127.0.0.1 53454 9229 0 - 0 0 0 - - - RECEIVE

Luckily there is a way to allow listening for loopback connections in UWP apps. The documentation for this is phrased as if it only applies to IOT, but it works on my desktop.
https://docs.microsoft.com/en-us/windows/iot-core/develop-your-app/loopback#enabling-loopback-for-a-uwp-application

CheckNetIsolation.exe LoopbackExempt -is -n=package family name

Using this tool I can get a debugger to start connecting to the JS engine, but it seems like there are still some kinks to work out.

[akrantz]

Debugging using the source map files will work properly with Visual Studio Code.

[chrisglein]

I'm working on getting direct debugging hermes/v8 into RNW. You may assign this to me.

Hey @mganandraj , it's been awhile since this statement and the issue is assigned to you. Can you capture where you are with this and what work remains?

[nasadigital]

Hey @mganandraj , it's been awhile since this statement and the issue is assigned to you. Can you capture where you are with this and what work remains?

@chrisglein I reached out to @mganandraj and I will pick up this issue (if possible).

[flavinger]

Hi @kmelmon and @nasadigital, is the guidance here on @kmelmon's wiki page current? Is there any additional work planned?

One small gripe about using the setup described in your wiki page is that if a developer wants to be able to switch between VS Code debugging and other tools like RN Debugger to monitor console output/React DevTools/Redux DevTools, it sounds like they would need to edit dev settings in their native app code every time to turn web and direct debuggers on and off.

[kmelmon]

@flavinger thanks for the feedback! The current support is admittedly not very polished yet. This task is tracking adding proper support. When we're done, you shouldn't have to make any code changes or rebuild to debug.

[chrisglein]

This is working for Chakra. It feels like for V8/Hermes we should track specific issues.

[chrisglein]

@mganandraj and @nasadigital , where are we in this? We have a direct debugging experience in place, and I want to make sure we're tracking the right concrete next steps. Do we think tracking them via this issue is appropriate? Or can we move on to more scoped individual issues?

[nasadigital]

@mganandraj and @nasadigital , where are we in this? We have a direct debugging experience in place, and I want to make sure we're tracking the right concrete next steps. Do we think tracking them via this issue is appropriate? Or can we move on to more scoped individual issues?

Thanks for reaching out!
My understanding is that there is support, but some work needs to be done on reliability and streamlining the developer experience. I am not sure, so I would need to double check and break down the work in tasks.
For tracking progress, I am not very familiar with what are best practices for github. Perhaps if I updated this project it would do the job?
What do you think?

[nasadigital]

@chrisglein
To my understanding direct debugging currently works with visual studio.
Some remaining work items are:

• Adding visual studio code support.
• Updating the wiki with instructions on direct debugging.

My suggestion is opening issues for the remaining tasks and closing this one.
The following board tracks Hermes support (including direct debugging support): https://github.com/microsoft/react-native-windows/projects/25
Would that make sense?

[chrisglein]

@chrisglein Chris Glein FTE
To my understanding direct debugging currently works with visual studio.
Some remaining work items are:

• Adding visual studio code support.
• Updating the wiki with instructions on direct debugging.

My suggestion is opening issues for the remaining tasks and closing this one.
The following board tracks Hermes support (including direct debugging support): https://github.com/microsoft/react-native-windows/projects/25
Would that make sense?

Yes, that sounds great. Please open new issues for the specific missing parts and close out this one.