Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] Preparing for Turbomodules #1226

Closed
molant opened this issue Mar 18, 2020 · 3 comments
Closed

[Discussion] Preparing for Turbomodules #1226

molant opened this issue Mar 18, 2020 · 3 comments

Comments

@molant
Copy link
Contributor

molant commented Mar 18, 2020

Hello all,

I'm opening this issue to start discussing what the future looks like once Turbomodules are GA. It looks like the current debugging experience will be broken in most cases and I think it will be good to start planning.

The gist of the linked conversation is that the only thing that will work is direct debugging. Depending on the target platform this could be a bit more complicated.

Android

The extension already supports Hermes with direct debugging so this shouldn't be an issue.
Do you know the distribution of engines used for Android apps? Should V8 taken into account as well (although hopefully it shouldn't be too complicated?).

iOS

This is more problematic as the only engine that can run is JSC so a proxy that converts its protocol to CDP will be needed. I believe the team already has experience with ios-webkit-debug-proxy but there seems to be an issue with iOS 12.3.1 and real devices.
Does that issue apply only to cordova or would it be the same for React Native? Also, it seems like the project has added support for iOS 13. Would that be enough to enable direct debugging on real iOS devices of React Native applications?

remotedebug-ios-webkit-adapter is another proxy package that seems to have solved the 12.3.1 issue but looks less maintained than the other one.

Windows

It already supports direct debugging. @acoates-ms what engine is/will be used? If it is V8 or Hermes it should hopefully not add a lot of extra work.

Something else that should be taken into account?

Thanks!

@alloy
Copy link
Member

alloy commented Mar 19, 2020

👋 I can say that at least attaching to JSC on a device running iOS 13.3.1 using ios-webkit-debug-proxy worked well using react-native’s RNTester application. (Didn’t try TurboModules specifically, though.)

@molant
Copy link
Contributor Author

molant commented Mar 21, 2020

The extension is migrating to a new debugger (see #1209) and the team has done a bit of research to see what it would take to make it work with Hermes.

The new debugger is js-debug and it uses flat sessions to allow debugging of all related pages and workers at the same time through a single connection using a targetId to route the message to the correct debug target.
Under the hood it uses Target.attachToBrowserTarget, but Hermes doesn't return any target, just an empty response. While this is not a blocker right now because the extension can keep using vscode-chrome-debug-core to debug Hermes applications, it might become in the future once the flattened protocol becomes the default and Target.attachToTarget gets deprecated. Also it is js-debug the one receiving all updates nowadays so we definitely want to use the new debugger sooner rather than later.

Will ping the Hermes team to see if this is under their radar.

@molant
Copy link
Contributor Author

molant commented Jul 23, 2020

The current thinking is to contribute back to Metro the proxy work so any CDP tool can debug react native applications on iOS.

We were told to start looking in https://github.com/facebook/metro/tree/master/packages/metro-inspector-proxy

@SounD120 can you use https://github.com/facebook/react-native/tree/master/RNTester to test things or do you need a way to test direct debugging on iOS?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants