Align [Shell|Process]Task#identifier

[jrieken]

I have still not understood why we have #identifier in shell and process task and it still feels like we are leaking an implementation detail but if we do so it should be called id to align with Extension#id and SourceControl#id

[dbaeumer]

We have an identifier to reference a task contributed by an extension in the tasks.json. You can do the following in a tasks.json

{
	"version": "2.0.0",
	"tasks": [
		{
			"taskName": "gulp: build",
			"identifier": "gulp.build",
			"problemMatcher": "$tsc"
		}
	]
}

This references the build task defined in gulp via its identifier. In the tasks.json a user can add problemMatchers and tweak other attributes. For example users ask to tweak the name.

I used identifier since the tasks.json has already the concept of an identifier in other places. To keep things consistent inside the task world I used identifier in the API as well. However I have no problem to rename it to id if we want to stay consistent inside the API world. Let me know what you advice.

[jrieken]

We have an identifier to reference a task contributed by an extension in the tasks.json.

So I can create an API task that is referenced in tasks.json to create another (or replacement) task? I didn't know that was possible. How do I know those identifiers and if how do I know what those referenced tasks actually do?

I see how I can hook up a somewhat generic NPM task with a problem matcher but I wonder if we can just have some like this

{
	"version": "2.0.0",
	"tasks": [
		{
			"taskName": "gulp: build",
			"command": "npm run compile",
			"problemMatcher": "$tsc"
		}
	]
}

with really good IntelliSense for command which is done via an extension that simply registers a completion item provider for **/.vscode/tasks.json? With that we would avoid the task+tasks.json<>task loop

[dbaeumer]

This is exactly what we want to get rid of. It is better that these commands come from an extension instead of having them statically in the tasks.json. This is what makes it hard for extension to evolve there stuff (for example if they detect the need to change the command or pass different arguments for different OS, ...)

An you don't need to know these ids. You can simply do (clicking the gear button next to a contributed task):

All the extensions needs to do is to keep the identifier stable.

[dbaeumer]

Moving to June since we moved the API back to internal.

[jrieken]

Should we maybe have something like a TaskTemplate which is such a cookie cutter task and then a ordinary Task which cannot be customised? I think of a task that publishes a build and has a custom output reader. My feeling is that it would feel alien in tasks.json

[dbaeumer]

In the early days of task 0.1.0 we had two sections for this. tasks and something like taskAnnotations. Was confusing at least from the feedback at that time. So in task 0.1.0 we decided to do the matching by name. However since task can now come from extensions there is a potential of a name conflict (two calling their tasks build :-)). So I decided to go with an id which makes it more stable. In 0.1.0 with gulp autodetection this looked like this:

{
	"version": "0.1.0",
	"command": "gulp",
	"isShellCommand": true,
	"tasks": [
		{
			"taskName": "build",
			"problemMatcher": ["$tsc"]
		}
	]
}

which basically annotates the build task coming from gulp with a $tsc problem matcher.

[dbaeumer]

Addressed in the new API.