Support for --inspect-brk=0 for node.js debugging.

[Dzenly]

Hi!
Since node.js 8.1.0 --inspect-brk=0 is used for random debugger port.
nodejs/node#5025

For now, VS Code 1.24 does now support such a situation. It fails to attach to process.
So, support this please.

Just in case, WebStorm supports this, so let's catch up. :)

WebStorm support answered me how they do it:

for child processes we do parse parent process output with regexp to get the port number. But note that this only works if the child process inherits stdio from parent.

[weinand]

For this feature the node-debug extension could track the data showing up in the integrated terminal and watch for Debugger listening on ws://127.0.0.1:30141/58fc5394-8411-4747-b550-f5f7ded20e44 and find a debug port (30141) there.

@Tyriar you showed some reservation when I mentioned elsewhere "to scan the data in the integrated terminal". I assume that performance is your main concern. Instead of sending the data to an extension we could reverse this by allowing an extension to push the scanning into the terminal, e.g. by accepting a regular expression. In this case only successful matches would be sent back to the extension.

What's your take on this?

[Tyriar]

@weinand well it would still need to match every line of every(?) terminal which is less than ideal as well. Is the only way to detect this by reading the output of a command?

One possible other solution is to extend the "command aware" terminals idea in which we guess which lines are commands and which are not #20676. You can see this in action by using cmd+up/down to navigate between commands in the terminal, it's not perfect and some cases aren't caught (for example if you type a command while output is happening), but might be good enough to use for this.

The command could then be matched on, say you register a terminal command listener for /node.*--inspect-brk.*/ or something and then the output for only that command will be sent over. That would allay any performance concerns I would have as commands are not recognized very frequently. It would also be a pretty cool general purpose extension API to be able to get the output of certain commands.

---

@dbaeumer does tasks allow scanning and acting upon output on the electron-browser process (not ext host)?

[Tyriar]

Actually maybe this wouldn't work as it wouldn't catch things like ./debug.sh or npm run debug

[weinand]

yes, I think that's what WebStorm is doing.

We tried to get away with this by finding the command line arguments via the "ps ..." command (or your highly tuned node module for Windows).
But for the --inspect-brk=0 case "0" is not the correct port but just an indication for node to pick a free port. And that port only shows up on the output...

There is another technique to find all open ports of an application but if a program has more than one port open, we do not know which one is the debug port...

When launching in the debug console, we can scan the output ourself because we capture the output anyway. But this is not the realistic use case because the debug console is only used by VS Code and VS Code already knows the debug port anyway.

[weinand]

Yes, capturing output and scanning for something like "Debugger listening on ws://127.0.0.1:30141/58fc5394-8411-4747-b550-f5f7ded20e44" would support any script and not only commands named "node".

[dbaeumer]

@Tyriar tasks for scan the output of the terminals which execute tasks. But I don't provide API for others to do that even not on the renderer side.

[june07]

microsoft/vscode-node-debug2#235

[weinand]

The new "js-debug" supports --inspect-brk=0scenarios.