Add type property for preLaunchTask

[meganrogge]

Idea from @alexr00:

In order to reduce the number of activations, we could add a type property to the preLaunchTask so that we know which extensions, if any, to activate when a user starts debugging and don't have to activate all of them.

No extensions are activated for type shell

preLaunchTask: {
      "name": "Ensure Prelaunch Dependencies",
      "type": "shell"
}

or

Only npm extension is activated

`"prelaunchTask": {
    "taskType": "npm",
    "taskLabel": "npm: build"
}

[connor4312]

Correct me if I'm wrong -- I don't know all the intricacies of the task system by far -- but doesn't the label string already reference a task defined in the tasks.json, and could we read the type from there?

[meganrogge]

the task might not be contributed in the tasks.json file - it might be contributed via the extension's call of registerTaskProvider

another issue - label is optional

[meganrogge]

Based on logging, I'm seeing only the relevant extension activated when I start debugging. Same for when I run the default build task.

Example using the terminal ext sample:

[meganrogge]

So, I believe that we're only activating all extension providers when we cannot find the right one in the tasks.json file.

[meganrogge]

One can already add a type property but needs to also provide a script.

The repro for this is set preLaunchTask to be the default build task.

[meganrogge]

So ideally, we'd check if the tasks.json file contains the default build task before activating all providers.

[connor4312]

Referencing preLaunchTask: "npm: start" with this in my tasks.json, it still activates all task providers before running it:

    {
      "type": "npm",
      "script": "start",
      "problemMatcher": [],
      "label": "npm: start",
      "detail": "echo hello"
    }

It's hard for me to give good input here as I don't really know how tasks work in relation to preLaunchTask. In the docs we only say that prelaunchTask can be set to "the label of a task specified in tasks.json". I don't have a good grasp on any implicit behavior outside of that. It seems like:

• They can reference labels in the tasks.json, as documented
• They can also reference tasks provided on the fly by task providers -- how would a user know what label to set this to when provided dynamically? Or is this only really relevant to programmatically generated launch.jsons?
• As discussed in 157957, they can be objects, but only for task types that are provided by extensions. Is it the case that this just allows extension-provided tasks to be "inlined" into the config? (There's no intellisense here so we don't provide any hints for users to go off of)

[meganrogge]

I think I have a solution. We should only be activating when the build task is actually run. I see we're activating earlier than that, which can be prevented.

[meganrogge]

Closing this issue. We don't need to add a type property, just need to be smarter about when and what we activate.

[meganrogge]

Currently, when ${defaultBuildTask} is used as a preLaunchTask we fetch all tasks, activating all providers, then filter to find the default build task.

Instead, I think we should try to find a default task in the tasks.json, wait to activate until it's run.

If there isn't one, then we'll fall back to the current behavior - activating all providers.