Allow users to customize tasks provided from TaskProvider

[ejizba]

I'm attempting to move over to TaskProvider for our extension rather than custom shell tasks. Per these docs, the TaskDefinition provided through TaskProvider is used "To uniquely identify a task in the system", but I don't just want to "identify" the task, I want to let users customize it as well.

For example, we want to provide a task that starts the Azure Functions host before a user debugs. The launch.json would look like this:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Attach to JavaScript Functions",
      "type": "node",
      "request": "attach",
      "port": 5858,
      "preLaunchTask": "func: host start"
    }
  ]
}

And I would provide the "func: host start" task like this:

export class FuncTaskProvider implements TaskProvider {
    public async provideTasks(token?: CancellationToken | undefined): Promise<Task[]> {
        const taskDefinition: TaskDefinition = { type: 'func', command: 'host start', port: 5858 };
        const task: Task = new Task(
            taskDefinition,
            'host start',
            'func',
            new ProcessExecution('func', ['host', 'start', '--language-worker', '--', `--inspect=${taskDefinition.port}`]),
            '$func-watch'
        );
        return [task];
    }
 
    public async resolveTask(task: Task, token?: CancellationToken | undefined): Promise<Task> {
    }
}

However, as soon as I try to change the port, I get an error like this:

Error: The func task detection didn't contribute a task for the following configuration:
{
    "type": "func",
    "command": "host start",
    "port": 5959,
    "problemMatcher": [
        "$func-watch"
    ]
}
The task will be ignored.

cc @dbaeumer continuing the conversation from here: #57707. You mentioned this issue #4758, but that seems focused on prompting users. We don't want to prompt users at all - we just want to give them the ability to customize if necessary.

[dbaeumer]

This is currently not possible. The closest duplicate is #43782.

One option would be to put the port into the settings since a task can reference settings values. But then you need to remove the port from the TaskDefinition.

[Hezkore]

@dbaeumer
I've spent like 4 days trying to figure out how to let the user customize the provided extension tasks.
But I kept getting the "The task will be ignored." message.
It sounds insane to me that this isn't implemented yet.

Is there any way to work around this?
Could the extension perhaps provide a normal shell task.json somehow?

[dbaeumer]

The problem here is if the property you want to let the user configure is a defining property of the task (e.g. it goes into the tasks key). In this case the tasks are different and there is no way to match these tasks.

However since the issue got opened VS Code has introduced the concept of a CustomTask where the extension can control everything itself.

Just to clarify: the resolveTask hook (as explained earlier) is not to change properties of a task. It is imagined to be a performance optimization so that a task provider can provide task stubs (including all arguments that make the key) and add the rest later.

Can you provide an example of what exactly you want to achieve?

[Hezkore]

Oh I haven't seen any CustomTask example so far.
But basically what I want to do is just let the user configure the build task a lot more.
Ideally I'd let them change everything in the build task really.
Like what architecture this is building for, output dir, if threads should be supported, etc.

[dbaeumer]

Actually what you want is to have a separate Process or Shell task based on task's properties. One idea would be to support access task properties as variables as we allow settings and environemt. Something like task:port. @alexr00 what do you think about this?

[ejizba]

Just to clarify: the resolveTask hook (as explained earlier) is not to change properties of a task.

I think my biggest confusion here is that I assumed TaskProvider.resolveTask was modeled after DebugConfigurationProvider.resolveDebugConfiguration, which says the exact opposite in the first line of the description:

Resolves a debug configuration by filling in missing values or by adding/changing/removing attributes.

Couldn't you do the same thing for tasks?

[dbaeumer]

The resolveTask is actually modeled after the languages API like CompletionProvider#resolve.

However I see the confusion. @EricJizbaMSFT to make things consistent we should think about a resolveTaskConfigurationthen. But I am not sure if this is necessary if we can access task properties in shell and process configurations.

[alexr00]

I think some sort of additional task property could be useful, but I'm not sure where the user should set it. It isn't something you would want to commit in a repository, so I don't think it makes sense to have in tasks.json.

[ejizba]

The resolveTask is actually modeled after the languages API like CompletionProvider#resolve.

Fair enough, but debugConfig and tasks feel much more related and so I think it's more important for those two to have consistency. In both cases, you're providing a json configuration to a file in the .vscode folder that is usually commited to your repo. Also debug config can often rely on a task.

to make things consistent we should think about a resolveTaskConfiguration

That still confuses me. After all, DebugConfigurationProvider.resolveDebugConfiguration already has a 1:1 mapping of the word DebugConfiguration just like TaskProvider.resolveTask has a 1:1 mapping of the word Task.

But I am not sure if this is necessary if we can access task properties in shell and process configurations.

I'm not entirely following this. Can you give a more detailed example?

It isn't something you would want to commit in a repository, so I don't think it makes sense to have in tasks.json.

As discussed in my original comment, we provide a task to run the Azure Functions host on your local machine for a functions project. We've had users report that they have multiple projects in one repo and they want to run both at the same time. They immediately run into problems because of conflicting ports. It would be great if they could customize one of their tasks to have a non-default port and I think it makes sense for them to commit that change.

@dbaeumer suggested putting the port in a settings file which is a decent workaround, but it still feels more natural if the user can customize a task right in their tasks.json.