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

Debugging JSC directly #7

Open
axe-fb opened this Issue Aug 6, 2018 · 10 comments

Comments

Projects
None yet
8 participants
@axe-fb
Copy link
Collaborator

axe-fb commented Aug 6, 2018

What

The ability to attach to JSC directly to debug React Native JavasScript code.

Background

Currently, we use Chrome to run the JS code when React Native is in the debug mode. When we start the debug mode, a new web socket connection is established via the packager to an instance of Chrome. We then use Chrome developer tools to debug the JS code. Similar mechanisms are used in the VSCode debugger for React Native, and the Idea react native plugin.

Why

When Native Modules today use a synchronous API, Chrome debugging fails. Sync API for native modules are not common, and at many places, such module provide alternative async calls.
With Fabric, there would be many more cases that utilize the synchronous API. Fabric will also use the new JavaScript Interface (called JSI), which lets JavaScript hold references to C++ objects.
Both these cases may not debuggable with the current setup.

How

There are currently two possible approach to support debugging in the future for OSS React Native projects.

  1. Support Synchronous debugging in Chrome. For this, whenever we move over from WebSockets to Sync-XHR whenever a synchronous API is encountered. This could be slow, and may not support the concept of Host Objects.

  2. Use Node for Synchronous debugging - Currently VSCode uses this approach. Instead of starting Chrome, it starts up Node, and debugs node using the node debug protocol. Node has support for Synchronous HTTP/XHR, so this could be leveraged. We still need to see how JS holding references to C++ objects would work.

  3. Debug JSC directly on the device - this seems to be the best approach, but may also require the maximum amount of work. Currently, Safari allows JSC on the device to be debugged directly. The JSC that we use in Android is pretty old and may not support debugging. We would need to find a good debugging story.

Side Note - We would also need to start supporting debugging Chakra in case of RN-Windows.

@gwmccull

This comment has been minimized.

Copy link

gwmccull commented Aug 10, 2018

I think the debugging in Node would be cool. I'm guessing that would mean you could use the Node in an Electron app (ie, React Devtools) to do the debugging which could allow developers to build some pretty powerful debugging interfaces

@axe-fb

This comment has been minimized.

Copy link
Collaborator Author

axe-fb commented Aug 10, 2018

Not really use Node in electron. I just mean that instead of JSC, the JS code will run on Node, and debuggers could be attached to Node.

@sahrens

This comment has been minimized.

Copy link

sahrens commented Aug 21, 2018

Would it really be "Node"? Wouldn't it be more like just using V8 directly as the VM, like NativeScript does? "Node" implies a whole set of runtime environment and builtins that we wouldn't want.

@sahrens

This comment has been minimized.

Copy link

sahrens commented Aug 21, 2018

But I also don't see a great reason to use V8 instead of Chakra if Microsoft is going to get Chakra working anyway for windows.

@Salakar

This comment has been minimized.

Copy link

Salakar commented Sep 15, 2018

With 2) having the bundle running in NodeJS is super cool 🙃 have been doing this myself for quite some time now to e2e test native modules - with JS code coverage. Can do things like e2e testing native modules just by using NodeJS testing frameworks (mixed in with detox for example).

For reference this is where I do that:

Debugging/bundle in NodeJS seems like the simpler approach / more user-friendly I think - would also open up a few dev tooling options like JS code coverage.

In terms of 3) I remembered the software mansion guys had an Android repo that had JSC debugging for RN - https://github.com/SoftwareMansion/react-native-android-jsc-debugging - if it helps as a reference for anything.

@kelset kelset referenced this issue Oct 9, 2018

Closed

0.58.x Discussion #41

@axe-fb

This comment has been minimized.

Copy link
Collaborator Author

axe-fb commented Oct 15, 2018

cc @RSNara

@csotiriou

This comment has been minimized.

Copy link

csotiriou commented Oct 20, 2018

I believe that debugging the code into the device itself is the best option. There are differences between Javascript platforms, such as Node and JavascriptCore. I see this every day I am trying to debug RealmJS. Debugging on the end device is the best approach, in my opinion.

The fact that the Android JSC runtime is pretty old should not be a show-stopper - it should be upgraded either way in order to properly add 64-it support (and other features such as Proxy objects etc, which are used by Libraries such as Mobx 5.x).

Edit. before you decide, read this:
realm/realm-js#491 (comment) . Realm is an impressive piece of technology - in this case they are right - React Native should have proper debugger support.

To be honest, I switched to Haul a while ago. Debugging in Safari was a breath of fresh air for me, since the JS code runs in the device and not in my browser - and I can debug it there. Using Node is a step back in my opinion. It will provide a hack, but this kind of short term decisions are the ones that got us talking about switching debugging methodology in the first place. I believe we should solve this once and for all and provide a way to debug JSCore in the device.

@kelset

This comment has been minimized.

Copy link
Collaborator

kelset commented Jan 8, 2019

Heads-up, the new JSC landed on master so the main blocker for option 3 I think that now is "gone".

commit -> facebook/react-native@f3e5cce

@matt-oakes

This comment has been minimized.

Copy link

matt-oakes commented Jan 9, 2019

I believe that the only major barrier to using Safari Debugging is the lack of sourcemaps. We might be able to fix that by including inline sourcemaps for dev builds?

This project also has a good example of how to bridge from the JSC debug protocol to a Chrome compatible one (and hence VSCode and others):

https://github.com/RemoteDebug/remotedebug-ios-webkit-adapter/

@fantasy525

This comment has been minimized.

Copy link

fantasy525 commented Feb 8, 2019

Is it possible to achieve debugging experience like native debugging?using chrome need open a chrome window,I think it is unnecessary,I just want to debugging in vscode or any other IDE.

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