Making auto-attach work with Deno

[lucacasonato]

Hey folks!

I'm one of the maintainers of Deno. js-debug has already works pretty well with Deno, but I was wondering if we could chat to y'all about how to make it work even better. For example, we're hearing from many people that they'd like auto-attach to work with Deno. We are very interested to make this work natively - for example by automatically reading the VSCODE_INSPECTOR_OPTIONS and connecting to the inspector (bypassing the bootloader.js script entirely).

We are also working on network panel support right now, and it'd be great to expose that in VS Code too when debugging Deno. Also hooking up the inspecting of workers and subprocesses would be really awesome.

We're happy to do all the work here. It'd just be great to figure out how to best do this without getting in your way too much. You can reach me at luca (at) deno.com too :)

[connor4312]

Hi! I would be happy to help with a solution for this 🙂 Note that the bootloader is what drives debugging in general, including the JavaScript Debug Terminal, in addition to auto attach.

The bootloader does several things which I think are useful to stick around:

• It synchronously starts the attachment back to js-debug and waits for the debugger to call Runtime.runIfWaitingForDebugger before executing the user's program. This is similar to the behavior of --inspect-brk, but some communication needs to happen here because the process listens on a random port and that needs to be given to js-debug.
• It avoids doing that if the 'lease file' created by the debugger doesn't exist, to avoid blocking forever if debug mode has exited.
• It can filter using the various attachment patterns in the "smart" auto attach mode. It also excludes some patterns found in dotfiles/npm's script wrappers, but I'm not sure whether those are applicable for Deno.

While this has been fairly stable recently, it's not super trivial and I don't think I would want VSCODE_INSPECTOR_OPTIONS to become contract, at least not at this point. The lifecycle is also tied to the specifics around how js-debug's attachment works which are likely not generally applicable to other clients.

On your latter two points:

• I implemented a basic network view in js-debug after seeing the Node.js announcement for experimental networking. It's off by default since their implementation is very basic right now but it can be turned on using a setting and works for browsers or when experimental networking is enabled for Node. If you implement the Network domain it should work for Deno too!
• Subprocess work automatically by inheriting the environment variables of their parent process. Wrt workers, Node implements their own NodeWorker domain. I would rather they have just used CDP's Target domain, and I implemented a 'translation layer' to Target. Reusing the NodeWorker domain would make it 'just work' for Deno but that does tie you a bit to Node's 'internals 🤷