Auto attach debugger to Node processes started from integrated terminal

[auchenberg]

Scenario
I as a Node developer use the integrated terminal to launch my Node.js app as I'm used to. My app starts, and now I want to debug. I could make a debug configuration to launch my Node app via VS Code, but that would be a new workflow for me. Instead I want VS code to be able to attach to my started Node process from the terminal.

Proposal
We should explore auto attaching to our Node debugger to the first Node process started from the integrated terminal.

Flow:

1. User starts process from integrated terminal. Ex npm start
2. User press F5
3. We auto detect the Node process started from the integrated terminal
4. Attach to that specific pID via our existing attach/pickProcess configuration.

This could either happen automatically as a part of our magic out of box experience, or through a new property in the debug configuration.

        {
            "type": "node",
            "request": "attach",
            "name": "Launch Program",
            "attachToIntegratedTerminal: true
        }

Rationale

• Encourage more users to use the integrated terminal.
• Leverage the benefits that we know which Node processes that were started from VS Code.
• Provide a end-to-end scenario without forcing developers to change their workflow by having them adapting launching from VS Code.

[auchenberg]

Suggestion from @roblourens: "What if in the existing process picker, we find processes that were started from the integrated terminal, and sort them to the top/highlight them?"

[weinand]

@auchenberg I've started a "Playground" extension for experimenting with this feature.

Since there is no API for accessing existing terminals, the extension just tries to automatically attach to all node runtimes that are in debug mode.

Ideas for more features:

• auto attach to node runtimes that are not in debug mode (via SIGUSR1),
• add a QuickPick for selecting potential candidates.

[Tyriar]

Here's the feature request to expose all the terminals to the API #13267, it's mainly just been waiting for compelling use cases. I've wanted to track the terminal process trees for a while as well to give a better experience for confirmOnExit, Windows already does this to track the active process title in the dropdown.

[auchenberg]

I like that experience @weinand, as the developer intentionally have chosen to enable ``--inspect`.

We could have the out of box experience like:

1. Auto detect and attach to Node processes started with debugging (like your extension)
2. Bump Node Child processes to the top in the QuickPick list when using an attach pickProcess config

I still can't decide whether pressing F5 for Node apps where we know a Node child process has been launched from the terminal should change behavior from today, as you can argue both ways.

That said I can easily imagine a workflow where I from my terminal type npm start, followed by a F5 where I then see the QuickPick list. I select my node process, and we send a SIGUSR1 to it, and attach the debugger. That way we don't have an intrusive experience, but we are more intelligent when you press F5 to enable debugging.

Today the experience somewhat falls apart if you already have started from the terminal, as we would try to launch the Node process again, and it would most likely fail as the port already is used.

This would be a change in the default F5 logic with no launch.json:

• If Node child process detected -> Attach with pickProcess config
• If no child process detected -> Attempt to launch like today.

What do you think?

[weinand]

@Tyriar tracking process trees for VS Code or the integrated terminal works as long as child process are created under a well known VS Code or integrated terminal process. But when running "tmux" in the integrated terminal, spawned process becomes children of a remote tmux server. So they are no longer part of the VS Code tree. Do you have any ideas how to track those processes?

[weinand]

The February exploration has been finished. For the next milestone it is planned:

• to add some of the logic to the node-debug process Picker
• to make the prototype a special mode of node-debug that can be turned on or off.