-
Notifications
You must be signed in to change notification settings - Fork 24.2k
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
[Debugger] Run RN JS within Node instead of Chrome #8641
![:octocat: :octocat:](https://github.githubassets.com/images/icons/emoji/octocat.png)
Comments
Also, because Node uses the v8_inspector protocol, this sets us up to support more debugging tools that understand that protocol. So other tools like VS Code and maybe Firefox w/Valence could inspect the Node JS context too. |
I've tried getting the inspector to work with a script loaded using What does work, however, is just deleting and setting things on the global object. |
Cool, let's start with that and also file a feature request with Node to add debugging support to contexts (nodejs/node#7593). Also, if we one day get the ability to make individual contexts inspectable, then we don't need to use |
Talking about running directly from something, can't we cut out the packager? |
We can't really do that because the child process would need to listen to WebSocket connections and then it wouldn't be a clean and isolated JS environment. I think it is also easier to have just one server that is responsible for connecting to the client. |
Not sure how the Nuclide debugger works in detail, but that should also be considered. |
@matthewwithanm wdyt? |
I’m completely naive about the JS/Node debugger protocols, but will this solution still allow for inspecting network requests in the Network panel of Chrome’s debugger? (Assuming you override |
This is exactly how RN debugging works in Nuclide today 😊. We run this script in a new process which downloads and runs the bundle in a sandboxed VM context. Then we debug that process. |
This will go away since the JS environment will be closer to the actual RN environment than Chrome's. On Android you can use Stetho to debug network requests, on iOS we use Charles Proxy. |
It looks like jam3/devtool supports the Network panel since it's just sanitizing an Electron environment. And since Electron is used, we could automatically use Keep in mind there are some "gotchas". Any thoughts? |
Ok. I’m not opposed to going back to using a proxy to debug network requests, but it was a nice integrated feature. Anyways, I’ve been wondering, isn’t the ultimate solution to expose the required debugger protocol from e.g. JavaScriptCore on iOS and run the JS code there like it would in production? (We have already been bitten in the past by not being able to reproduce a crash on iOS 8 because the stdlib during debugging was different than it actually was on the device.) To be clear, this is just thought for the future, not something that should supersede the effort of this ticket imo. |
The problem is that the Network panel works because RN is using Blink's implementation of
Absolutely, it already works on iOS + Safari and gets better with each iOS + OS X release. With iOS 10 and Sierra I believe that JS profiling is supported (haven't tried it though), in addition to breakpoints and other standard fare. It doesn't work on Android at the moment though, so that's a big blocker. I suspect that on-device debugging is something we will have to implement one day especially because of synchronous JS hooks -- if the JS VM needs to synchronously call into native code or vice versa, there's an obvious impedance mismatch with asynchronous WebSockets. |
Regarding debugging network connections, RN is getting built-in support: f20d5ed |
Awesome 👌 |
Has there been any work done on this? It would be nice to get the React dev tools back. 😁 |
@ide are you still working on this? |
I haven't put any coding time into this. The fact that no one (including myself) has worked on it makes me think it's maybe not truly that important but I'm happy to be proven wrong with a PR. |
OK, I'm going to close this issue for now then under the principle of general malaise. I also would be happy to be proven wrong with a PR! |
![:octocat: :octocat:](https://github.githubassets.com/images/icons/emoji/octocat.png)
The goal of this issue is to run RN's JS within Node instead of Chrome to reduce the number of moving parts and asynchrony.
How things currently work
Currently when turning on Chrome debugging, RN on the device opens a WebSocket connection to the packager server, which opens a small page in Chrome that opens another WebSocket connection to the packager:
RN then sends the bundle URL to the packager, which forwards it to Chrome. Chrome then creates a Web Worker in which the bundle JS is executed. So there's quite a bit of asynchrony here:
How we can simplify this
Node 6.3 supports V8's debugger out of the box. Node gives you a link that we can open in Chrome, and it shows a full-screen debugger that is focused solely on JS and not the other browser features. So, we no longer need to run the JS in Chrome for it to be debuggable with familiar tools. This is the new plan:
Already you can see there's one less asynchronous communication step, and we replace the second WebSocket connection with
child_process.fork
, which is easier to set up and keep alive.Things to figure out
importScripts()
in the Web Worker to load the JS bundle. With Node that doesn't exist, so we'll need to manually download the script to a temporary location on disk and then run it. This isn't hard; just something that needs to be done.vm.runInContext
from within the Node child process.Launch plan
We should keep the Chrome debugger alive for at least a month (two RN releases) or perhaps until Node 6 hits LTS (October 1). My sense is the event that actually matters is when Facebook is able to use Node 6 internally -- once that happens FB probably won't want to maintain the Chrome debugger and will want to focus on just the Node debugger instead.
The text was updated successfully, but these errors were encountered: