Work out plan to move community to direct debugging

[acoates-ms]

Introduction

Various upcoming react-native features are going to start requiring that developers debug JS directly against the JS engine running on the device instead of remote JS debugging (or web debugging) that is commonly used today. This includes TurboModules and Fabric, which do not work unless the JS is running on device. In addition even without using these things code has been slowly diverging between web debugging, and direct debugging. (View Configs being an obvious example).

We need to work out a transition plan to move people away from using web debugging, and to start using direct debugging.

Discussion points

How can we identify what are the current blocking issues preventing people from using direct debugging?

How can we encourage people to use direct debugging instead of web debugging?

Web debugging already causes warnings in view configs - should we have an additional more explicit warning, maybe with instructions on how to direct debug instead?

When can we remove web debugging?

We probably wont know for sure until we get a better sense of what gaps currently exist, but could it be marked as deprecated in 0.63, then removed in 0.64? Is that too quick?

[kelset]

Thanks for opening this discussion @acoates-ms!

So, I think that there was a sort-of similar conversation started almost 2 years ago by @axe-fb -> #7

I think that the main "broad community" reason for using the web debugging is just "ease of use" - if I'm understanding what you mean with web VS device. Just to make sure: if I'm debugging an app installed in the simulator does that fall in the web debugging part? What if I'm using Flipper?

We probably wont know for sure until we get a better sense of what gaps currently exist, but could it be marked as deprecated in 0.63, then removed in 0.64? Is that too quick?

Sorry, need to ask clarification question about this too. Basically you are envisioning to deprecate the "Remote Debugging" button from the dev menu when in debug mode for a RN app?

[elicwhite]

cc @rickhanlonii, as I believe he is working on bringing the Hermes Debugger to Flipper which should make it easy to debug on Android for people using Hermes. I'm not sure if there are plans for iOS though.

Also cc @RSNara and @hramos as TurboModules rolling out will be the forcing function that will make the Chrome Proxy Debugger no longer work. We'll need to have a plan to get people off of that.

[slorber]

Hi,

I'm a heavy user of the Chrome debugger.

Not totally sure what you mean by "direct debugging", except maybe that the JS runs on the phone and not in Chrome.

Can we do direct debugging today easily?
Is there an article to explain how to set this up and give it a try?
Does Flipper allow direct debugging?

[terrysahaidak]

I'm and lots of folks from my company (as well as 1,167,438 installs on vs-marketplace) are addicted to VSCode debugger and React Native Tools. Direct debugging is going to break such an excellent and easy DX.

I've been avoiding Chrome debugging (as well as all the all-in-one solutions where it also has React Devtools and redux Devtools) because it's just hard to use, it slow to load source maps, I've been constantly switching context from VSCode to chrome and back, Chrome in the background runs the app slower, etc.
console.log was my favorite debug thing.

But everything has changed once I tried React Native Tools and debugger just inside the VSCode. It's just as much convenient as using Android Studio or XCode to debug native code.

Direct debugging is such a big step back here.

I didn't find an answer yet. I know we cannot use the Chrome Debug Protocol anymore. But maybe we can start thinking about something that can replace it and provide some interface to VSCode as Chrome Debug Protocol did?

[axe-fb]

One of the original authors of the VSCode Extension here.
The VSCode debugger (and the React Native extension) is actually using the same mechanism as the Chrome debugger, except it runs the code on Node instead of Chrome. Thats one reason why source maps faster.
Hermes uses the Chrome Debug Protocol, and VSCode does understand that. I am assuming that moving VSCode extension to use Direct DEbugging is easy. Given the protocol, other debugging clients may also be able to connect.
Also, I think direct debugging is better than where we are today, mostly because you are debugging on the JS engine that the code will run on - ensuring that JS differences between engines dont hurt us.

[kelset]

Can it maybe be clarified what "Direct Debugging" is? It really feels like it'd help a lot to make sure we all are well aware of what it is VS Web Debugging.

[terrysahaidak]

In my understanding, direct debugging is the debug process when you connect to the VM itself - for example, the way we debug web view on Android using remote devices menu in devtools.

Is direct debugging forces us to use that approach (the same for iOS using Safari) or it's just the term which represents the way it's going to work under the hood, so we will be able to workaround everything and connect directly to VM from VSCode or Flipper plugin.

[acoates-ms]

Sorry, obviously I needed to flush out what I meant by direct debugging.

I'm referring to attaching to the JS engine which is running on the device. Hermes, and V8 certainly support the Chome Debug Protocol, which means you would be able to attach either VSCode, or Chrome directly to your device. The JS is still running on the device, so turbo modules and other things that rely on native JS function hooks, JSI, or synchronous native modules continue to work.

This is different than the remote JS debugging where the JS runs in chrome (or VSCode).

I think direct debugging should be relatively trivial to get to work today with Android. I'm less clear where iOS stands. My understanding is that the only mechanism to do this with the built in JSC is to use Safari debugging. -- which I gather is a less pleasant devX.

What I was envisioning is that in addition to the Remote JS option in the debug menu currently, there would be an option to put the JS engine in to debug mode, which would allow any Chrome Debug Protocol compatible debugger to attach. (VSCode, chrome etc). (In react-native-windows we've supported direct debugging for ages, but I'm in the process of making it more discoverable by adding it to the debug menu there too)

At the very least we need to start getting the experience of direct debugging to be as good or better than the remote JS debugging, so that its not another blocker / shock when people try to start using turbomodules.

[terrysahaidak]

What about using a tool to proxy Chrome Devtools Protocol to JSC?

Few of them:
https://github.com/google/ios-webkit-debug-proxy
https://github.com/RemoteDebug/remotedebug-ios-webkit-adapter

[usrbowe]

@terrysahaidak I tried to use the one from Microsoft (it's built on top of work from Google), but can't seem to proxy JSCore. Only works with Safari. Maybe need to do some change in RN code. But I have feeling we might not need a proxy as we already have a metro running the Chrome Debugger Protocol proxy. It's done for Hermes debugger.
So maybe can reused metro and try to expose JSCore.