Suggestion: Add a label to the generated func host start task in tasks.json

[jkewley]

I'm not sure if this is the correct place to suggest this. I spent some time looking for the proper repo, but came back here after not being able to identify the correct place.

The boilerplate tasks.json which is generated by function tooling produces this default task:

    {
      "type": "func",
      "command": "host start",
      "problemMatcher": "$func-node-watch",
      "isBackground": true,
      "dependsOn": "npm install (functions)"
    },

I think this is the bit of code that produces it.

The issue with the tooling is that it is using a hard-coded reference to this configuration for validation checks. This breaks the F5 debugging experience if, for example, you want to send the --verbose switch into the command to diagnose an issue.

    {
      "type": "func",
      "command": "host start --verbose",
      "problemMatcher": "$func-node-watch",
      "isBackground": true,
      "dependsOn": "npm install (functions)"
    },

Now the tooling can't find the task because the task name has changed to func: host start --verbose. Instead it complains of a missing task.

There is an easy fix for this - include a label for the task:

    {
      "type": "func",
      "command": "host start --verbose",
      "label": "func: host start",
      "problemMatcher": "$func-node-watch",
      "isBackground": true,
      "dependsOn": "npm install (functions)"
    },

Adding this label to the template would cut down on confusion caused by changing the default task

Related - since functions version 2.x, the command has changed from func host start to func start per this page. I'm guessing there's a backwards compatibility reason for using the old command, but I figured I'd bring it up, as it's tangentially related.

[wwlorey]

We're leaning towards supporting arguments for the func task but we need to investigate. It's possible that a catch-all could be added to the task matcher but we think that was avoided for a reason.

[ejizba]

Generally the Functions extension should be able to handle any variation of func start/func host start/etc., but you are correct that the launch.json and tasks.json have to match. I believe VS Code ignored the "label" property on custom tasks (aka provided in a TaskProvider) back in the day, but if it's working today this should be relatively trivial to add to projects by default