Support User Level Tasks

[tsmaeder]

VS Code now supports defining tasks at the user level: https://code.visualstudio.com/updates/v1_42#_user-level-tasks

Since we're already using PreferenceConfigurations for reading tasks from source folders, it would be logical to extend the same approach to user-level configurations.

The problems here is that our current preference merging algorithm would override the task defined at user level, when the desired behavior (as observed in VS Code) would be to merge the list of user tasks.

[marcdumais-work]

cc @elaihau : Liang, I think you've been involved in a lot of the development in this area. Coul you assist Thomas with related questions he may have?

[tsmaeder]

I did a little experiment with a VS Code extensions doing the following:

const value= vscode.workspace.getConfiguration('tasks');
vscode.window.showInformationMessage(JSON.stringify(value));

When I add a task to ~/AppData/Roaming/Code/User/tasks.json and either have no folder open or I have no tasks.json in <open folder>/.vscode, I see the tasks from the user settings in the workspace configuration.
As soon as I configure a task into <open folder>/.vscode/tasks.json, I no longer see the user-level tasks in the workspace configuration.

So it seem like tasks are indeed treated differently whether you are accessing them through the configuration API or the tasks UI.

[tsmaeder]

When I change the code to do

		vscode.tasks.fetchTasks().then((value)=> {
			console.info((JSON.stringify(value));
			vscode.window.showInformationMessage(JSON.stringify(value));
		});

I see the tasks from the user settings in the output.

[akosyakov]

@tsmaeder thank you! It sounds like the change should be applied only to task extension?

[tsmaeder]

Yes, I believe so, but slightly disappointed at VS Code for the inconsistency ;-)

[tsmaeder]

A couple of experiments I ran:

1. When referencing a task in "depends on", the match is done via the "name" of the task. Setting the label property overrides the name, otherwise it seems to be what the detecting provider set as the name.
2. A task is considered a configuration of a detected task if it matches all of the properties of the detected task: example:

{
            "label": "this is the build",
            "type": "npm",
            "script": "build",
            "path": "examples/browser/"
}

As long as I keep "type", "script" and "path" the same, this will always count as a configuration of the "npm: build - examples/browser" detected task. If I change any of them, it's not related anymore.
3. Tasks seem to be the considered "the same" if all of the properties defined in their task definition are the same.
4. Tasks of type 'shell' or 'process' are the same when the have the same label, otherwise they are different.

I haven't yet done any experiments with "scope", though.

[tsmaeder]

Note: the document here seems to indicate that stuff in tasks.json can only ever be a "customization" of a contributed tasks, but that is not the case: you can create tasks of type "npm", for example that are not considered customizations of a contributed task.
Our code currently seems to make that erroneous assumption. I believe we could simplify that code if we drop that constraint.

[tsmaeder]

@elaihau I was wondering why we allow multiple TaskDefinition object for the same task type. How would we have to different definitions for the "npm" task type? I

[elaihau]

@elaihau I was wondering why we allow multiple TaskDefinition object for the same task type. How would we have to different definitions for the "npm" task type? I

when i wrote that part of the code i followed the vscode design to achieve the compatibility.

Take typescript-language-features extension for example, https://github.com/microsoft/vscode/blob/6fded8a497cd0142de3a1c607649a5423a091a25/extensions/typescript-language-features/package.json#L921
it contributes only one task definition, however, as you can see from the JSON, it has the flexibility of contributing more than just one.

Since I have never seen any extensions that contribute more than one task definition, to answer your question I can only make guesses :)
Imagine we have an extension git-commands, we could probably contribution 2 task definitions, one for simple git commands such as git status, and the other for more complex commands such as git stash save & git stash drop:

    "taskDefinitions": [
      {
        "type": "gitSimpleCommands",
        "required": [
          "command"
        ],
        "properties": {
          "command": {
            "type": "string"
          },
          "option": {
            "type": "string"
          }
        }
      },
      {
        "type": "gitComplexCommands",
        "required": [
          "command1",
          "command2"
        ],
        "properties": {
          "command1": {
            "type": "string"
          },
          "command2": {
            "type": "string"
          },
          "option": {
            "type": "string"
          }
        }
      },
    ],

You might want to argue that gitSimpleCommands and gitComplexCommands could be combined into one task definition - I agree with you. My point is, I guess accepting more than just one task definitions from same extension offers the developers more flexibility.

[tsmaeder]

@elaihau I understand that the same extension can contribute more than one task definition, but can more than one task definition contribution have the same type field? Because the code in TaskDefinitionRegistry seems to indicate that there can be more than one tasks definition for "typescript", for example. "typescript" as the task type, not the extension. If I write an extension that also contributes a "typescript" task type, I think that would be an error, no?

[elaihau]

You are right @tsmaeder . In Theia, although our API looks compatible with vscode's, we don't actually have code to support having more than one task definitions per extension/plugin, because we don't have anything that stores the associations between extension/plugin and task definition names.

It is definitely something we should improve :)

[tsmaeder]

@elaihau not what I'm talking about: I am talking about more than one definition for the same type
There can be a many task definitions per plugin, but no two of those definitions can have the same value for "type", so the following should be rejected:

"taskDefinitions": [
      {
        "type": "foo",
        "required": [
        ],
        "properties": {
            ...
        }
      },
      {
        "type": "foo",
        "required": [
        ],
        "properties": {
            ...
        }
      }
]

but the one below is correct:

"taskDefinitions": [
      {
        "type": "foo",
        "required": [
        ],
        "properties": {
            ...
        }
      },
      {
        "type": "bar",
        "required": [
        ],
        "properties": {
            ...
        }
      }
]

[elaihau]

ah, got it. we don't throw any errors if multiple task definitions having same names are defined under the same extension/plugin. And we should.

[tsmaeder]

I don't think VS Code does either, but didn't check real well...

[tsmaeder]

Well, just added a task definition of type "npm" into my test extension: VS Code indeed just seems to take the last definition it sees: no error is signalled.

[tsmaeder]

Note: the document here seems to indicate that stuff in tasks.json can only ever be a "customization" of a contributed tasks, but that is not the case

Actually not true: you need to have a contributed tasks, otherwise you can't run the task

[tsmaeder]

Other fun experiment: Contribute two tasks with the exact same values (origin, name, scope, type, ...) and VS Code will happily treat those two as different tasks. I think contributed tasks have identity. We seem to address tasks through "label", "source", "scope". Not sure that is correct.

[tsmaeder]

prefs-explorer.zip

Here's the test extension I'm using.

[elaihau]

prefs-explorer.zip

Here's the test extension I'm using.

Thank you Thomas ! This is really helpful !