Why is "type" a mandatory parameter for an "attach" config?

[pcj]

It seems like this should be a valid debug configuration, but it is not:

{
    "version": "0.2.0",
    "configurations": [
        {
            "request": "attach",
            "debugServer": 4711,
            "name": "Attach to a running Foozilizer Debug Server"
        }
    ]
}

If I have a binary that implements the DAP, I can create a launch.json "attach" configuration that should be able to talk to it, right out of the box. Yet, VSCode insists that a "type" also be configured on the attach configuration, which must match up with a debugger provider in some package.json. Why? In this case it seems that vscode should have all the information it needs to perform a debug session without the help of some vscode.debug.registerDebugConfigurationProvider (the "type" implementation of registerDebugAdapterDescriptorFactory and/or registerDebugConfigurationProvider can do essentially nothing).

It would be nice to be able to connect to an artitrary debug adapter without first having to download an extension that "provides", well, not very much.

(or, is there some generic "type" that can be used in the launch.json?)

[connor4312]

"attach" in VS code doesn't refer to how the connection to the debug server is made, this is independent of the launch config. For example, for JavaScript debugging, "attach" will attach to a Node.js process with its debugger opened on a certain port, but that debugger speaks CDP and the DAP debugger is implemented as an inline DebugAdapter executable. Saying that "attach" requests don't have any additional config and just attach to an existing DAP-speaking server is insufficient for scenarios like this.

[pcj]

If I declare that my extension contributes this:

        "debuggers": [
            {
                "type": "starlark",
                "label": "Starlark Debug"
            }
        ],

And have an implementation like:

import * as vscode from 'vscode';

export class StarlarkDebugger implements vscode.DebugAdapterDescriptorFactory {
    constructor(
        disposables: vscode.Disposable[]
    ) {
        disposables.push(vscode.debug.registerDebugAdapterDescriptorFactory('starlark', this));
    }

    async createDebugAdapterDescriptor(session: vscode.DebugSession, executable: vscode.DebugAdapterExecutable | undefined): Promise<vscode.ProviderResult<vscode.DebugAdapterDescriptor>> {
        return new vscode.DebugAdapterServer(4711);
    }
}

It satisfies the requirement of providing a debugger.

But, all this implementation seems to be doing is replicating what are already the default values for an attach config!

The docs say this:

debugServer - for debug extension authors only: this attribute allows you to connect to a specified port instead of launching the debug adapter.

So, perhaps what I'm suggesting is that a the type attribute should default to "dap" or similar, which would by default speak dap over the debugServer port.

This would allow users to "bring your own debug adapter" and start a debug session without first having to install any extensions that, in this example, only provides the name "starlark", and nothing else.

(which IMHO follows the KISS principle quite nicely)

[connor4312]

A simple extension is free to make a dap-type config that does something simple like this, as you suggest. You could publish that on the marketplace if you want to 🙂 But usually debuggers are built for specific languages and generally require additional steps or at least have configuration for attachment, so they're more complicated than your example. That's why configuration and API is built like it is in Vs Code, and I don't see any benefit to making such functionality a built-in extension versus something installable from the marketplace for specific scenarios.

[pcj]

Fair points. Personally, I think it would be a point of recognition/badge of honor for vscode, and the dap protocol for that matter, to be able to run a debug adapter without any additional configuration, since, well... it already can :)

I suspect a PR to add such a feature would only be a few lines.