Optionally allow launch.json to overwrite the debugee configuration

[Adin Baskoro]

Problem Statement

Oftentimes, the debugee configuration differs from project to project. By optionally allow launch.json to overwrite the debugee configuration, one can easily switch from one project to another without cluttering the configuration list, as the list will only show the relevant configurations for the project.

Ideas or possible solutions

One possible solution is to add an overwrite flag at the end of dap.ext.vscode.load_launchjs arguments as follows:

load_launchjs({path}, {type_to_filetypes}, {overwrite})

If the overwrite flag is true, then the loaded launch.json overwrites dap.configurations[filetype]. Else, it extends dap.configurations.

Currently I'm using that approach in my setup, and it's working well for me.

[Mathias Fußenegger]

Isn't it possible to clear out the existing configurations before calling load_launchjs to accomplish the same?

What would be the key, name and type?

[Adin Baskoro]

Isn't it possible to clear out the existing configurations before calling load_launchjs to accomplish the same?

You're correct. I just find it neat to include the functionality in the API as I think it's a common use case. I don't find this as a deal breaker though, as it's quite easy to script it ourselves outside the plugin.

What would be the key, name and type?

At the moment I wipe the configuration based on the file type. For example, if I load the following launch.json:

{
    "version": "1.0.0",
    "configurations": [
        {
            "name": "Debug MyApp",
            "type": "go",
            "request": "launch",
            "program": "github.com/me/myapp/cmd/myapp",
            "args": [
                "-f", 
                "config.toml"
            ]
        }
    ]
}

dap.configurations["go"] will be wiped and replaced with the one from launch.json

A bit tangent, but I wanted to be able to easily keep the predefined global configurations (for example, the ones loaded during startup from lua files), while also able to freely swap launch.json files if that makes sense. However, I settled on the approach I explained in the original post as it's good enough for my use case.

[Mathias Fußenegger]

I'm not too keen on adding parameters to do something that can be done in a single line up-front

What I could imagine is either changing the behavior to try to merge configuration entries by type and name or to have an additional method that does that.

[Adin Baskoro]

Understandable. I'll close this issue.

What I could imagine is either changing the behavior to try to merge configuration entries by type and name or to have an additional method that does that.

I'm also looking at this. Maybe I'll be back if I have something in line with that, but anyway thanks for your response!