I noticed that we sometimes have to hardcode a "port" in a launch config if we want to use the same port in restarted debug sessions. Here is an example from the MERN Starter Recipe (see https://github.com/weinand/vscode-recipes/tree/master/MERN-Starter):
"protocol": "inspector",
"runtimeExecutable": "nodemon",
"runtimeArgs": [
"--inspect=9222"
],
"port": 9222,
"restart": true, The ugly thing about this is the redundancy (and potential inconsistency) between the protocol, runtimeArgs, and port attributes. If the value of protocol is changed to legacy, the values for runtimeArgs and port must be changed as well, otherwise a problematic inconsistency will occur.
It would be preferable if we could just use this:
"protocol": "inspector",
"runtimeExecutable": "nodemon",
"restart": true,
In this case the debug adapter picks a random port and passes it with the correct 'inspect' or 'debug' option to the runtime.
The problem is how this "port" can be looped from the DA back to VS Code and then to the next session.
I suggest that we support a generic mechanism for passing arbitrary data from one debug session to the next by extending the type of the restartattribute of the TerminatedRequest from "boolean" to "any".
VS Code will loop this restart value unmodified and uninterpreted from one session to a restarted next session as the (already existing) __restart attribute of the launchRequest.
I noticed that we sometimes have to hardcode a "port" in a launch config if we want to use the same port in restarted debug sessions. Here is an example from the MERN Starter Recipe (see https://github.com/weinand/vscode-recipes/tree/master/MERN-Starter):
The ugly thing about this is the redundancy (and potential inconsistency) between the
protocol,runtimeArgs, andportattributes. If the value ofprotocolis changed tolegacy, the values forruntimeArgsandportmust be changed as well, otherwise a problematic inconsistency will occur.It would be preferable if we could just use this:
In this case the debug adapter picks a random port and passes it with the correct 'inspect' or 'debug' option to the runtime.
The problem is how this "port" can be looped from the DA back to VS Code and then to the next session.
I suggest that we support a generic mechanism for passing arbitrary data from one debug session to the next by extending the type of the
restartattribute of theTerminatedRequestfrom "boolean" to "any".VS Code will loop this
restartvalue unmodified and uninterpreted from one session to a restarted next session as the (already existing)__restartattribute of thelaunchRequest.