A DAP launcher/option to stick to single session plain DAP mode

[mickaelistria]

See discussion on #902 (comment) .
To make the Debug Adapter reusable by other clients (in place of node-debug2), we need a way to start the Debug Adapter in a "plain DAP" mode where the vanilla DAP workflow works, eg without need to interact with non-DAP standard attachedDebugSession requests. This basically means ignoring everything related to sessions in the public facade.
A suggestion is to add a --runInBand flag (to flatSessionLauncher I guess).

[robbienohra]

any update on this?

[connor4312]

No updates, and this would not be possible to do correctly without changes to DAP. Take an evaluate request for example: when connected to a target with children (such as a webpage with a webworker), where does the evaluate go to? It can do different things in different contexts, and would not have any way to tell the difference.

You could implement some ad-hoc 'adapter adapter' that would only be able to evaluate when a frameId is given, and implement similar scoping or rough-fitting for other DAP features. It's a square peg into a round hole, but with enough sanding it could be made to fit. If the community would find such a thing valuable and has an interest in maintaining that, I would be happy to provide pointers and some kind of basic compatibility guarantee (e.g. say a certain way of launching js-debug will always work.) However, I do not have the time or desire to build such a system myself at this time.

When DAP support arrives for hierarchal sessions, though, I will certainly adopt it in js-debug. If you have inspiration for how that should work, I'd encourage you to share it in microsoft/debug-adapter-protocol#79!

[mickaelistria]

You could implement some ad-hoc 'adapter adapter' that would only be able to evaluate when a frameId is given, and implement similar scoping or rough-fitting for other DAP features.

Most DAP-able clients would pass a frameId as the DAP spec can suggest. So it's a pity that this debugger cannot support that case and cannot "just work" if plain DAP is used and frameId is set. I think the limitations like the one you mention here are not really blockers for DAP support as they are not really part of the typical DAP spec or usage.
I believe most people here are not looking for full support of all vscode-js-debug feature over DAP, but just 1 easy way to use a subset of vscode-js-debug over DAP, instead of node-debug2.