Does this also fix the issue where launch configs with prelaunchTask will enable everything as well? That one seems to be going through a different code path.

Does this also fix the issue where launch configs with prelaunchTask will enable everything as well?

It should; when testing with following configuration, no additional extensions are activated:

• .vscode/task.json:

  {
      "version": "2.0.0",
      "tasks": [
    	  {
    		  "type": "npm",
    		  "script": "test",
    		  "group": "test",
    		  "problemMatcher": [],
    		  "label": "run 'npm: test'",
    	  }
      ]
  }
  

• .vscode/launch.json:

  {
      "version": "0.2.0",
      "configurations": [
          {
              "type": "node",
              "request": "launch",
              "name": "Launch Program",
              "skipFiles": [
                  "<node_internals>/**"
              ],
              "program": "${workspaceFolder}/t.js",
              "preLaunchTask": "run 'npm: test'"
          }
      ]
  }
  

I tried your above steps and am not seeing the extension get activated when I run an npm task (no status bar item). When I run a command from that extension, I do see it.

I see it work when I use a different extension with onTaskType though. Looks like they've removed that

Whoops, I forgot my own repro steps :D. It needs to be a preLaunchTask set to ${defaultBuildTask}, and then one of the tasks in tasks.json needs to have

"group": {
  "kind": "build",
  "isDefault": true
}

Even if it doesn't fix that case, this is still a good improvement!

(Also, I suppose for clarity: I do not work on VS Code despite the "Member" tag)

It needs to be a preLaunchTask set to ${defaultBuildTask}

Looked into it and it's not the task that is the problem; it's the variable: when launching, it first tries to resolve all variables present inside the config:

When i replace the line above with following code, it works:

let resolvedConfig = configByProviders;
resolvedConfig.preLaunchTask = 'run \'npm: test\'';

I think it's best to fix this issue in another PR, or should it better be included in this one?

Digged depper into this and it seems that the current behaviour regarding ${defaultBuildTask} is correct:

When resolving ${defaultBuildTask}, vscode needs to find all buildtasks first to then filter out the default ones; since all extensions can contribute tasks, all extensions need to be launched here.

I think it's best to discuss this behaviour and any possible change in this in a new issue.

Yes @Mai-Lapyst you are correct in your understanding and that is why I said in the original issue that the behavior was expected.