Repository: vscode
Issue: Provide Task Runner viewlet
Labels: feature-request,tasks,ux

<!-- Do you have a question? Please ask it on http://stackoverflow.com/questions/tagged/vscode -->

We did a Task 2.0 deep dive today and this issue collects the combined feedback received. 

### Task Properties

- echo should be true by default so that users get a better idea of the task executed
- we should support flattening the JSON properties as we do with other settings (e.g `"terminal.echo": true` instead of `"terminal": { "echo": true }`
- we should better separate task declaration from task customization. Currently both happens in the tasks array property and the differentiating element is the `customize` property.

### Task Picker

The task picker should support a decription / detail message to better explain what the task does. We also discussed whether the task picker should support MRU which would automatically move the most used tasks up to the top without customization. If we provide a task panel (see below) such a MRU list could be useful there as well.

### Task Customization

The task customization is currently instance based where the task instance is identified by a task id, which can be quite 'cryptic'. An alternative way would be to identify a task based on a type and a key that is defined by the type and therefore can vary from task runner to task runner. So instead of having something like:
```json
	{
		"customize": "vscode.npm.run build",	
		"taskName": "npm: run build"
	}
```

a customization would look like this

```json
	{
		"customize": {
			"type": "npm",
			"file": "${workspaceRoot}/package.json",
			"script": "build"
		},
		"problemMatcher": ["$tsc"]
	}
```

where the structure of the identifying attribute is defined by the extension providing the runner support. In the example above the fact that a npm script is identified by the location of the package.json file and the script name comes from the npm extension. This might look different for task contributed by gulp of TypeScript

### Problem Matchers

For task that execute a target of a task runner (e.g. gulp, npm, grunt) VS Code can't decide which problem matchers to attach. Since picking the right problem matcher currently requires editing the tasks.json file we should better support the user with this. We discussed the following ideas:

- always attach all known problem matchers if a task has no problem matchers. This might result in false positives and might require us to support removing problem matchers via a configuration mechanism.
- we could help the user attaching a problem matcher by generically scanning the output for problems and suggest problem matchers that exactly match these. If selected we update the tasks.json file for the user.

### Task panel

It was suggested to run tasks in its own panel instead of reusing the terminal panel. They should still be executed using the terminal to get ANSI control character support and other nice terminal features (e.g. Ctrl+C). The panel could offer additional features like:

- a task summary (execution time, exit code, ...)
- the output of a task could be folded (like travis does for example)
- allow for in place customization of a task (for example attach a problem matcher) without the user being forced to edit a tasks.json file.

We also discussed the need of a task viewlet but decided that this will not add any big additional value over the task picker and a separate panel.

### Top Level Menu

We were also discussing whether the tasks deserve a top level menu. In general this was consider a good idea. However such a menu should be semantically not technical. So instead of naming it Tools or Tasks it would be better to offer top level menus like Build, Rebuild All, Clean, Run Tests. The downside of such an approach is that such a menu looks out of place if none of these entries trigger any meaningful action in the workspace (e.g. if a simple JS project is open at lease Build, Rebuild All and Clean don't make any sense) 

### Better Selfhosting

Would be great if we can improve the self hosting coverage of tasks. This is currently hard to do due to the fact how we build. But @dbaeumer will tweak our tasks.json to support more tasks currently run in the terminal (e.g run tests, linting, ...)