Multi-root: support Compound debug configurations across workspace folders

[auchenberg]

With multi-root its quite common to have back-end and front-end projects as separate folders loaded in the same workspace. Today a compound defined in one workspace folder doesn't seem to be able to reference another workspace debug config

We should enable compound debug configurations to work across workspaces, to enable a full-stack debug experience. We already provide a aggregated debug config list in the Debug UI.

[isidorn]

I think this feature request makes perfect sense. But I would wait a bit for users to pick up multi root workspaces and see if users jump on this feature before doing anything here.

[weinand]

@auchenberg in your initial comment you said

Today a compound defined in one workspace folder doesn't seem to be able to reference another workspace debug config.

I assume that you've meant:

Today a compound defined in one workspace folder doesn't seem to be able to reference another debug config in a different folder of the same workspace.

I've changed the title of this issue to reflect this.

[weinand]

We have to decide whether a compound launch config spanning different folders is only allowed in a workspace launch config or in individual folder launch configs. The former case is covered by feature request: #36967

[auchenberg]

You could make the argument that a workspace compound should be within <workspace>/.vscode/launch.json in order to be able to reference a specific launch config within a workspace folder.

[Disane87]

Is there an estimated release date for this?

[weinand]

One part of this feature is a new syntax for root-folder based variables.
See this related feature request: #38977

[weinand]

This work is planned for December/January.

[weinand]

Topics:

1. How to reference a launch config that lives in a different root folder in a compound launch config?
2. Is there a general mechanism to scope variables to another root folder? (Add variable substitution to refer to a specific root folder of a multi-root workspace #38977)
3. Is a compound launch config spanning different folders only allowed in a workspace launch config? (Support Workspace launches in a MR workspace #36967)

Topic 1:
Assuming that the server lives in a folder "server" and the client in a folder "browser/client" the proposed syntax looks like this:

"compounds": [
    {
        "name": "Start Server & Client",
        "configurations": [ 
            {
                "folderPath": "server",
                "configName": "Launch server"
            },
            {
                "folderPath": "browser/client",
                "configName": "Launch client"
            }
        ]
    }
]

The "folderPath" attribute is optional which makes it possible to use the new syntax in the single folder case too.

Topic 2:
We will use the syntax ${<variable>:<folderPath>} e.g. ${workspaceRoot:browser/client}
This is only allowed in configuratinos which live in the workspace launch config file. For regular launch configs this should result in an error or be ignored.

Topic 3:
Referring to folders is only allowed in a workspace launch config. Using the folderPath syntax elsewhere results in an error.

[auchenberg]

On top my head, my gut expectation would be to use <workspaceRoot>/<configName> in the configurations` array, such as

    "compounds": [
        {
            "name": "Compound",
            "configurations": [
                "api/node launch",
                "frontend/chrome"
            ]
        }
    ]

[weinand]

@auchenberg yes, that was basically Isidor's and my proposal but it was voted down as "unintuitive" in our standup meeting.
@roblourens your opinion?

/cc @VScode

[weinand]

I've created issue #41779 to address the fundamental issue that workspace folders have no stable ID.

@isidorn topics 1 and 2 are blocked until #41779 has been addressed. But we can proceed on 3.

[roblourens]

I would resist adding an ID to every workspace folder, and use the folder's path, like "folderPath" in your proposal. It seems very intuitive to me. It would make the compound config much more readable, if I see the real path to the folder, rather than some random number ID.

[auchenberg]

+1 on avoiding another unique ID.

Do we know what the usage ratio between relative and absolute paths are? Currently I like the simplicity of compounds being a simple array of strings. The nested object structure as proposed in Topic 1) feels very heavy.

[weinand]

Yes, I do not like an additional (and unreadable) ID either.
I would rather like to use the folder "name" that is shown in the explorer as an ID (option 2 in #41779). This would support the lightweight syntax proposed by @auchenberg and others.

Just using the "path" doesn't work for me because "path" is not stable.
If the path of a workpace folder is changed, folder references using that path are broken.
Using the volatile attribute "path" as the primary key for a folder doesn't feel right.

[isidorn]

Now we support the following:

• Adding launch configurations in your workspace folder "launches" section
• Variable replacment scoped per folder, example ${workspaceFolder:kenneth} this will get replaced with the path of my workspace with name kenneth. This should work nicely for all variables
• A compound can reference any configuration in a workspace simply by specifiying its name in the configurations array
• In case the configuraiton does not have a unique name a compound can reference it using the following syntax configurations: [{ "name": "Launch Program", "folder": "kenneth" }, "mySecondUniqluelyNamedConfig"]

Try it out and let me know how it goes.