Hey guys, React Native Tools team here. During migration of the extension on js-debug we found out that Node debugging scenarios doesn't support inspectUri argument for discovering debugging target websocket via debugging proxy as browser scenarios does. Is it possible to add such an argument for Node scenarios?
Node debugging hooks up differently than Chrome, so it's not a super trivial change--there's no existing pathway where we go out and make a websocket connection to a debug target in Node. Are you trying to do something that doesn't work with the inspectUri shim present in the Chrome configs?
@connor4312 In React Native extension there is a special debugger worker process that communicates with the application JS bridge. The whole debugging workflow is tied to this pure Node process. And since our debugging case in React Native extension is about debugging Node, I think Chrome debugging scenarios will not work for it.
Upd: you can find more information about current RNT debugger architecture here, maybe it will be useful
@connor4312, we tried to add a support of inspectUri parameter to Node Attach scenario (for now it's just a PoC). inspectUri parameter was added to Node Attach scenario configuration and handled almost the same way as for Chrome cases. The parameter was passed to watchDog process for establishing a connection with CDP proxy over Node debugger. With this configuration we can debug React Native applications, but it turned out that for some reasons breakpoints processing time increased. Now it takes a second or even longer to handle a breakpoint. Is this an expected behavior? Do you know what could cause this?
Also, we saw an update in vscode-cdp-proxy, and it seems to be very useful for us. Could you please publish a new version of that package so we could add it to the extension as a dependency? Thanks.
Have you tried this with a "chrome" type config using inspectUri? Even though you are actually attaching to a Node process, since we are just attaching to some websocket using CDP, it shouldn't matter.
Do you need to attach to any child processes that are spawned by the Node process? I don't think so, you are just debugging the one process, right?
Yes, we need to debug only one debuggerWorker Node process.
We tried to use Chrome attach scenario and found out the following:
inspectUri parameter only in Launch scenario. But we'd like to use Chrome attach scenario to establish connection with a Node process over CDP proxy. So for now it doesn't work for us without modifications on the extension side.inspectUri parameter, but it didn't work. The connection to debuggerWorker was established successfully (acquireConnectionForBrowser method), but then the extension tried to get a page target using flat session API (e.g. BrowserTargetManager.connect and Target.attachToBrowserTarget methods). After that an unknown exception was thrown:
attachToBrowserTarget method returned undefined result.
inspectUri parameter support to Chrome attach scenario, we were able to attach to CDP proxy and log requests. The CDP proxy successfully attached to debuggerWorker too. So we got the following output:
Thus for now it seems that Chrome attach scenario doesn't suit to debug React Native applications with the React Native Tools current architecture.
we tried to add a support of inspectUri parameter to Node Attach scenario (for now it's just a PoC). inspectUri parameter was added to Node Attach scenario configuration and handled almost the same way as for Chrome cases.
I'm not totally sure I see why you need to do that versus using the existing port and/or host that's available on the node attach configuration? That's seems like the way to do things for this scenario as far as I can see.
With this configuration we can debug React Native applications, but it turned out that for some reasons breakpoints processing time increased. Now it takes a second or even longer to handle a breakpoint
If you have a sample where I could try this out that'd be awesome. Alternately you can take an extension host profile on your machine.
Could you please publish a new version of that package so we could add it to the extension as a dependency?
Done :)
@connor4312, thanks for publishing of vscode-cdp-proxy package. It may be that I'm missing something, but I don't see the way to use port and/or host parameters to pass ws address (inspectorURL) of debuggerWorker to CDP proxy to connect to it then. We'll be able to connect to CDP Proxy this way, but we'll need to do inspector websocket lookup for debugging target from the proxy side. From our understanding inspectUri should resolve such a problem.
I prepared small demo for testing React Native Tools based on CDP Proxy and modified Node attacher so you can try to debug an RN application using the following instruction:
vsix patched js-debug extension - js-debug.vsix.zip. The patch is related to https://github.com/RedMickey/vscode-js-debug/pull/1/commits/bd0fb1fe671907212a393f9312c01dbfdc720993 commit.
git clone https://github.com/RedMickey/rn-demo-button.git && cd rn-demo-button && yarn install
AppTestButton.js file and set a breakpoint on the line 10Debug Android debug scenarioDebug buttonI attach a GIF to demonstrate a delay of breakpoints processing. The time of processing could be a bit longer than real due to screen recording.

In the Node attach case, you're attaching to a process that is already started.
we'll need to do inspector websocket lookup for debugging target from the proxy side
I think this is the correct thing for you to do. The inspectUri is useful in the Chrome launch case because there's a lot of browser launching behavior that js-debug implements that would be impractical to reimplement in a the proxy. But if you already have a process running, it should be fairly trivial to do the websocket lookup there.
Thanks for clarification, it seems that implementation of inspectUri parameter won't make much sense for the extension in this case. So we are going to implement inspector socket lookup on RN extension side ourselves.
Most helpful comment
Thanks for clarification, it seems that implementation of
inspectUriparameter won't make much sense for the extension in this case. So we are going to implement inspector socket lookup on RN extension side ourselves.