Tasks: Multi Root Support

[bpasero]

This issue is for discussing the future of tasks in a multi-root environment. I see two interesting places where today a single root is assumed (there may be more I am not aware of):

• when resolving the tasks configuration (getConfiguration)
• when detecting tasks from files such as gulpfile.js (ProcessRunnerDetector)

IWorkspaceContextService.toResource() and getWorkspace() are deprecated in favour of IWorkspaceContextService.getWorkspace2() that contains information about all the roots.

We need to decide for tasks (and debug) if we just collect tasks from all workspaces or introduce a different concept to make this decision.

[dbaeumer]

Besides the technically decision this has huge impact on the user interface of tasks as well. If collected from all folders how do we present them in a single quick pick. Will we simply pre / postfix the task (which leads to a lot of identical strings in the UI). Will we group them. If all folders define a primary build task will we execute all build tasks when Task > Run Build Task is executed. Or do we need another UI to define which task to execute.

[bpasero]

We already have the necessary UI to group things in quick open, e.g. see here:

We could do something similar for the overall tasks list and respect the root folder order as the user configured it.

As for tasks triggered via keybinding I think we should introduce a setting to define which task should be executed. When not defined, we could still show a picker with the build or test tasks so that the user can make this decision each time the keybinding is invoked. Each entry in the picker could have a little configure action to guide the user to the setting.

[dbaeumer]

The task UI already uses grouping: So how would that look for group with group :-)

Regarding the setting. We have that already for a single tasks.json which is the primary task. So for multi root we then need a primary primary task which sounds a little strange.

[bpasero]

@dbaeumer we could show the folder name also as part of the meta property, we do this already for quick open for files:

[dbaeumer]

@bpasero this is what I mention in comment #29454 (comment). What I don't like about this is that the folder name will be often repeated which in general makes a not nice UI.

[bpasero]

@dbaeumer alternatively we could show tasks based on the active file that is currently open (by checking for its root folder if there is any) and in the picker have a "more..." entry that then shows a full list of tasks across all folders.

[bpasero]

After talking to @dbaeumer here is an alternative proposal:

• as a user you can configure task configurations for a multi root workspace
• this workspace level configuration is stored outside the workspace for the workspace (requires new configuration infrastructure)
• we always scan all task configurations from all folders that are opened and show the user this list with an action to promote one configuration to workspace level to be able to use it
• we allow to reference a specific task configuration from the workspace setting into one of the folders
• we allow compound configurations to start multiple

[borekb]

I've noticed TSLint rules are run per folder in 1.16 (hooray!), is it already possible to create tasks per folders such as this?

- projectA
  - tslint.json
  - .vscode
    - tasks.json
- projectB
  - tslint.json
  - .vscode
    - tasks.json

[dbaeumer]

No, this is on the plan for this month.

[ghiscoding]

Not sure if it's related, but you could add the task icon beside each task group (Gulp doesn't have the same icon as Grunt). I often use tasks of Gulp and NPM, that would help to distinguish them a bit more.

The task UI already uses grouping: So how would that look for group with group :-)

[dbaeumer]

Done :-)