Fix step-debugging in Workerd

[frandiox]

This PR enables step-debugging when using --worker-unstable in combination with --debug, as well as allowing external DevTools to connect to the workerd inspector.

The approach is a simplified version of what Wrangler does: it adds a server proxy between the workerd and the local debugger which:

• Filters all the active workers and only returns the main Hydrogen app worker, so that tools like VSCode can connect easily without specifying addresses (only a port). -- Related [Miniflare 3] Step debugging with multiple workers cloudflare/miniflare#735
• Allows logging to the terminal at the same time the debugger is enabled (without a proxy server, logs would only be ingested by the debugger).
• Fixes connection from external DevTools -- Related Unbreak chrome://inspect for workerd cloudflare/workerd#1390

To test the debugger in VSCode, add this to .vscode/launch.json and start the debugger after the app is running with h2 dev --worker-unstable --debug.

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Hydrogen",
      "type": "node",
      "request": "attach",
      "port": 9229,
      "cwd": "/",
      "resolveSourceMapLocations": null,
      "attachExistingChildren": false,
      "autoAttachChildProcesses": false,
      "restart": true,
    }
  ]
}

To test Chrome DevTools, open chrome://inspect and make sure the port 9222 is added to the network targets.

[frandiox]

The code in this file was extracted from mini-oxygen/workerd-inspector.ts and hasn't changed at all. Feel free to skip it in the review.

[blittle]

👀👀👀👀 😜

[blittle]

Verified it works in both VSCode and Chrome. A few thoughts:

1. It does not work with a "JavaScript Debug Terminal" presumably because VSCode isn't connecting to the right port. That's unfortunate, because the JS debug terminal is convenient without needing to setup a vscode launch config. I often prefer this because the port itself is variable (if something's already on port 3000, it goes to 3001). But probably it's not that likely to boot up multiple hydrogen apps at the same time? If so, perhaps down the road we could add a CLI init question around VSCode (do you use VSCode?). And if so, then automatically generate the launch config?
   

2. Not in scope for this work, but it would be great if we could also support something like --debug-brk to automatically pause at startup.

[blittle]

👍🏼

[blittle]

This is important, because the default port that chrome looks for is different than what we default to. I had to manually add 9222 for chrome to see it.

[frandiox]

In my browser, both 9222 and 9229 are by default added. However, VSCode only uses 9229 by default so I'm going to swap these 2 ports to make 9229 the public one and 9222 the private one for workerd 👍

[blittle]

I'm curious how you knew how to do this?

[frandiox]

Lots of this comes from Wrangler itself! But also it's documented in https://chromedevtools.github.io/devtools-protocol/#endpoints

[frandiox]

Thanks for the review!

It does not work with a "JavaScript Debug Terminal" presumably because VSCode isn't connecting to the right port.

Unfortunately, the JavaScript Debug Terminal can only attach to Node.js processes, it doesn't support connecting to an independent port :/

And if so, then automatically generate the launch config?

This is interesting, maybe we could do this automatically if we detect a .vscode folder at the root when using --debug? 🤔

Not in scope for this work, but it would be great if we could also support something like --debug-brk to automatically pause at startup.

I don't think we can make this work in workerd at the moment.
We could try sending an artificial Debugger.setBreakpoint event pointing to the first line of the worker (outside of fetch). However, we'd need to wait for workerd to send us first a Debugger.scriptParsed, and I think at that point the code in the outer-scope has already run (or will run soon enough and won't wait for our breakpoint event).