通过任务与外部工具集成
现存许多工具可以自动化诸如代码检查（linting）、构建、打包、测试或部署软件系统等任务。例如 TypeScript 编译器，像 ESLint 和 TSLint 这样的 linter，以及像 Make、Ant、Gulp、Jake、Rake 和 MSBuild 这样的构建系统。
这些工具大多从命令行运行，用于自动化软件开发内部循环（编辑、编译、测试和调试）内外的工作。鉴于它们在开发生命周期中的重要性，能够在 VS Code 内部运行这些工具并分析其结果是非常有帮助的。VS Code 中的任务可以配置为运行脚本和启动进程，这样许多现有的工具就可以在 VS Code 内部使用，而无需进入命令行或编写新代码。特定于工作区或文件夹的任务是在工作区的 .vscode 文件夹中的 tasks.json 文件里配置的。
扩展也可以使用 任务提供程序（Task Provider）来贡献任务，而这些贡献的任务可以添加在 tasks.json 文件中定义的特定于工作区的配置。
注意： 任务支持仅在处理工作区文件夹时可用。在编辑单个文件时不可用。
TypeScript Hello World
让我们从一个简单的“Hello World” TypeScript 程序开始，我们希望将其编译成 JavaScript。
创建一个空文件夹“mytask”，生成一个 tsconfig.json 文件，然后从该文件夹启动 VS Code。
mkdir mytask
cd mytask
tsc --init
code .
现在创建一个 HelloWorld.ts 文件，内容如下
function sayHello(name: string): void {
console.log(`Hello ${name}!`);
}
sayHello('Dave');
按下 ⇧⌘B (Windows, Linux Ctrl+Shift+B) 或从全局终端菜单运行运行生成任务，会显示以下选择器
第一个条目执行 TypeScript 编译器，并将 TypeScript 文件转换为 JavaScript 文件。当编译器完成后，应该会有一个 HelloWorld.js 文件。第二个条目以监视模式启动 TypeScript 编译器。每次保存 HelloWorld.ts 文件都会重新生成 HelloWorld.js 文件。
你也可以将 TypeScript 构建或监视任务定义为默认的构建任务，这样在触发运行生成任务 (⇧⌘B (Windows, Linux Ctrl+Shift+B)) 时就会直接执行。为此，请从全局终端菜单中选择配置默认生成任务。这会显示一个包含可用构建任务的选择器。选择 tsc: build 或 tsc: watch，VS Code 将生成一个 tasks.json 文件。下面显示的文件将 tsc: build 任务设为默认构建任务
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"type": "typescript",
"tsconfig": "tsconfig.json",
"problemMatcher": ["$tsc"],
"group": {
"kind": "build",
"isDefault": true
}
}
]
}
上面的 tasks.json 示例没有定义新任务。它只是将 VS Code 的 TypeScript 扩展贡献的 tsc: build 任务标注为默认构建任务。现在你可以通过按 ⇧⌘B (Windows, Linux Ctrl+Shift+B) 来执行 TypeScript 编译器。
任务自动检测
VS Code 目前能自动检测以下系统的任务：Gulp、Grunt、Jake 和 npm。我们正在与相应的扩展作者合作，以增加对 Maven 和 C# dotnet 命令的支持。如果你使用 Node.js 作为运行时开发 JavaScript 应用程序，通常会有一个 package.json 文件来描述你的依赖项和要运行的脚本。如果你克隆了 eslint-starter 示例，那么从全局菜单执行运行任务会显示以下列表
如果你还没有这样做，请通过运行 npm install 安装必要的 npm 模块。现在打开 server.js 文件，在一个语句的末尾添加一个分号（注意 ESLint starter 假设语句没有分号），然后再次执行运行任务。这次选择 npm: lint 任务。当提示使用哪个问题匹配器时，选择 ESLint stylish
执行该任务会产生一个错误，显示在问题视图中
此外，VS Code 创建了一个 tasks.json 文件，内容如下
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"type": "npm",
"script": "lint",
"problemMatcher": ["$eslint-stylish"]
}
]
}
这指示 VS Code 使用 ESLint stylish 格式扫描 npm lint 脚本的输出以查找问题。
对于 Gulp、Grunt 和 Jake，任务自动检测的工作方式相同。下面是一个为 vscode-node-debug 扩展检测到的任务示例。
提示： 你可以通过快速打开 (⌘P (Windows, Linux Ctrl+P)) 运行你的任务，方法是输入 'task'、空格和命令名称。在本例中，即 'task lint'。
任务自动检测可以通过以下设置禁用
{
"typescript.tsc.autoDetect": "off",
"grunt.autoDetect": "off",
"jake.autoDetect": "off",
"gulp.autoDetect": "off",
"npm.autoDetect": "off"
}
自定义任务
并非所有任务或脚本都能在你的工作区中被自动检测到。有时需要定义自己的自定义任务。假设你有一个脚本来运行你的测试，以便正确设置某些环境。该脚本存储在工作区内的一个 script 文件夹中，在 Linux 和 macOS 上名为 test.sh，在 Windows 上名为 test.cmd。从全局终端菜单运行配置任务，并选择从模板创建 tasks.json 文件条目。这将打开以下选择器
注意： 如果你看不到任务运行器模板列表，你可能已经在你的文件夹中有了一个
tasks.json文件，并且它的内容会在编辑器中打开。关闭该文件，并为本示例删除或重命名它。
我们正在努力支持更多的自动检测，所以这个列表将来会越来越短。因为我们想编写自己的自定义任务，所以从列表中选择其他。这将打开一个带有任务骨架的 tasks.json 文件。将内容替换为以下内容
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "Run tests",
"type": "shell",
"command": "./scripts/test.sh",
"windows": {
"command": ".\\scripts\\test.cmd"
},
"group": "test",
"presentation": {
"reveal": "always",
"panel": "new"
}
}
]
}
任务的属性具有以下语义
- label：任务的标签，用于用户界面。
- type：任务的类型。对于自定义任务，这可以是
shell或process。如果指定了shell，则命令被解释为 shell 命令（例如：bash、cmd 或 PowerShell）。如果指定了process，则命令被解释为要执行的进程。 - command：要执行的实际命令。
- windows：任何 Windows 特定的属性。当命令在 Windows 操作系统上执行时，将使用这些属性代替默认属性。
- group：定义任务属于哪个组。在示例中，它属于
test组。属于测试组的任务可以通过从命令面板运行运行测试任务来执行。 - presentation：定义任务输出在用户界面中的处理方式。在此示例中，显示输出的集成终端
always（总是）显示，并且每次任务运行时都会创建一个new（新）终端。 - options：覆盖
cwd（当前工作目录）、env（环境变量）或shell（默认 shell）的默认值。选项可以按任务设置，也可以全局或按平台设置。此处配置的环境变量只能在你的任务脚本或进程中引用，如果它们是你 args、command 或其他任务属性的一部分，将不会被解析。 - runOptions：定义任务何时以及如何运行。
- hide：在“运行任务”快速选择框中隐藏任务，这对于复合任务中不能独立运行的元素很有用。
你可以在你的 tasks.json 文件中使用 IntelliSense 查看完整的任务属性和值。使用触发建议 (⌃Space (Windows, Linux Ctrl+Space)) 调出建议，并在悬停时或通过阅读更多... ('i') 弹出窗口阅读说明。
你也可以查看 tasks.json 结构。
当命令和参数包含空格或其他特殊字符（如 $）时，Shell 命令需要特殊处理。默认情况下，任务系统支持以下行为
- 如果提供单个命令，任务系统会将该命令原样传递给底层 shell。如果命令需要引号或转义才能正常工作，则命令需要包含适当的引号或转义字符。例如，要列出一个名称中包含空格的文件夹的目录，在 bash 中执行的命令应如下所示：
ls 'folder with spaces'。
{
"label": "dir",
"type": "shell",
"command": "dir 'folder with spaces'"
}
- 如果提供了命令和参数，当命令或参数包含空格时，任务系统将使用单引号。对于
cmd.exe，则使用双引号。像下面这样的 shell 命令将在 PowerShell 中作为dir 'folder with spaces'执行。
{
"label": "dir",
"type": "shell",
"command": "dir",
"args": ["folder with spaces"]
}
- 如果你想控制参数的引用方式，参数可以是一个指定值和引用样式的字面量。下面的例子对一个带空格的参数使用转义而不是引用。
{
"label": "dir",
"type": "shell",
"command": "dir",
"args": [
{
"value": "folder with spaces",
"quoting": "escape"
}
]
}
除了转义，还支持以下值
- strong：使用 shell 的强引用机制，它会抑制字符串内的所有求值。在 PowerShell 以及 Linux 和 macOS 的 shell 下，使用单引号（
'）。对于 cmd.exe，使用"。 - weak：使用 shell 的弱引用机制，它仍然会求值字符串内的表达式（例如，环境变量）。在 PowerShell 以及 Linux 和 macOS 的 shell 下，使用双引号（
"）。cmd.exe 不支持弱引用，所以 VS Code 也使用"。
如果命令本身包含空格，VS Code 默认也会对命令进行强引用。与参数一样，用户可以使用相同的字面量样式来控制命令的引用。
还有更多的任务属性可以配置你的工作流程。你可以使用 IntelliSense 和 ⌃Space (Windows, Linux Ctrl+Space) 来获取有效属性的概览。
除了全局菜单栏，任务命令还可以通过命令面板 (⇧⌘P (Windows, Linux Ctrl+Shift+P)) 访问。你可以筛选 'task' 并看到各种与任务相关的命令。
复合任务
你也可以使用 dependsOn 属性将简单的任务组合成复合任务。例如，如果你的工作区有一个客户端和一个服务器文件夹，并且两者都包含一个构建脚本，你可以创建一个任务，在不同的终端中启动这两个构建脚本。如果你在 dependsOn 属性中列出了多个任务，它们默认会并行执行。
tasks.json 文件如下所示
{
"version": "2.0.0",
"tasks": [
{
"label": "Client Build",
"command": "gulp",
"args": ["build"],
"options": {
"cwd": "${workspaceFolder}/client"
}
},
{
"label": "Server Build",
"command": "gulp",
"args": ["build"],
"options": {
"cwd": "${workspaceFolder}/server"
}
},
{
"label": "Build",
"dependsOn": ["Client Build", "Server Build"]
}
]
}
如果你指定 "dependsOrder": "sequence"，那么你的任务依赖项将按照它们在 dependsOn 中列出的顺序执行。任何在 dependsOn 中与 "dependsOrder": "sequence" 一起使用的后台/监视任务都必须有一个问题匹配器来跟踪它们何时“完成”。以下任务将运行任务二、任务三，然后是任务一。
{
"label": "One",
"type": "shell",
"command": "echo Hello ",
"dependsOrder": "sequence",
"dependsOn": ["Two", "Three"]
}
用户级别任务
你可以使用任务: 打开用户任务命令创建不与特定工作区或文件夹绑定的用户级别任务。这里只能使用 shell 和 process 类型的任务，因为其他任务类型需要工作区信息。
输出行为
有时你希望控制运行任务时集成终端面板的行为。例如，你可能希望最大化编辑器空间，只在认为有问题时才查看任务输出。终端的行为可以通过任务的 presentation 属性来控制。它提供以下属性
- reveal: 控制是否将集成终端面板带到前台。有效值为
always- 面板总是被带到前台。这是默认值。never- 用户必须使用视图 > 终端命令 (⌃` (Windows, Linux Ctrl+`)) 显式地将终端面板带到前台。silent- 仅当输出未被扫描以查找错误和警告时，终端面板才被带到前台。
- revealProblems：控制在运行此任务时是否显示“问题”面板。优先于选项
reveal。默认为never。always- 执行此任务时总是显示“问题”面板。onProblem- 仅在发现问题时才显示“问题”面板。never- 执行此任务时从不显示“问题”面板。
- focus：控制终端是否获得输入焦点。默认为
false。 - echo：控制执行的命令是否在终端中回显。默认为
true。 - showReuseMessage：控制是否显示“终端将被任务重用，按任意键关闭”的消息。
- panel：控制终端实例是否在任务运行之间共享。可能的值有
shared- 终端是共享的，其他任务运行的输出会添加到同一个终端。dedicated- 终端专用于特定任务。如果该任务再次执行，终端将被重用。但是，不同任务的输出会呈现在不同的终端中。new- 该任务的每次执行都使用一个新的干净终端。
- clear：控制在运行此任务之前是否清除终端。默认为
false。 - close：控制任务运行所在的终端在任务退出时是否关闭。默认为
false。 - group：控制任务是否在特定的终端组中使用分割窗格执行。同一组中的任务（由字符串值指定）将使用分割终端来呈现，而不是一个新的终端面板。
你也可以为自动检测到的任务修改终端面板行为。例如，如果你想更改上面 ESLint 示例中 npm: run lint 的输出行为，可以向其添加 presentation 属性
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"type": "npm",
"script": "lint",
"problemMatcher": ["$eslint-stylish"],
"presentation": {
"reveal": "never"
}
}
]
}
你也可以将自定义任务与检测到的任务配置混合使用。一个配置了 npm: run lint 任务并添加了一个自定义 Run Test 任务的 tasks.json 文件如下所示
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"type": "npm",
"script": "lint",
"problemMatcher": ["$eslint-stylish"],
"presentation": {
"reveal": "never"
}
},
{
"label": "Run tests",
"type": "shell",
"command": "./scripts/test.sh",
"windows": {
"command": ".\\scripts\\test.cmd"
},
"group": "test",
"presentation": {
"reveal": "always",
"panel": "new"
}
}
]
}
运行行为
你可以使用 runOptions 属性指定任务的运行行为
- reevaluateOnRerun：控制通过重新运行上一个任务命令执行任务时如何评估变量。默认为
true，意味着当任务重新运行时将重新评估变量。当设置为false时，将使用任务上一次运行解析的变量值。 - runOn：指定任务何时运行。
default- 任务仅在通过运行任务命令执行时运行。folderOpen- 当包含该任务的文件夹被打开时，该任务将被运行。首次打开包含带有folderOpen任务的文件夹时，系统会询问你是否允许在该文件夹中自动运行任务。你可以稍后使用管理自动任务命令并在允许自动任务和禁止自动任务之间进行选择来更改你的决定。
- instanceLimit - 允许同时运行的任务实例数量。默认值为
1。
自定义自动检测的任务
如上所述，你可以在 tasks.json 文件中自定义自动检测的任务。通常这样做是为了修改表示属性或附加一个问题匹配器来扫描任务的输出以查找错误和警告。你可以直接从运行任务列表中自定义任务，方法是按右侧的齿轮图标，将相应的任务引用插入到 tasks.json 文件中。假设你有以下 Gulp 文件，使用 ESLint 来检查 JavaScript 文件（该文件取自 https://github.com/adametry/gulp-eslint）
const gulp = require('gulp');
const eslint = require('gulp-eslint');
gulp.task('lint', () => {
// ESLint ignores files with "node_modules" paths.
// So, it's best to have gulp ignore the directory as well.
// Also, Be sure to return the stream from the task;
// Otherwise, the task may end before the stream has finished.
return (
gulp
.src(['**/*.js', '!node_modules/**'])
// eslint() attaches the lint output to the "eslint" property
// of the file object so it can be used by other modules.
.pipe(eslint())
// eslint.format() outputs the lint results to the console.
// Alternatively use eslint.formatEach() (see Docs).
.pipe(eslint.format())
// To have the process exit with an error code (1) on
// lint error, return the stream and pipe to failAfterError last.
.pipe(eslint.failAfterError())
);
});
gulp.task('default', ['lint'], function() {
// This will only run if the lint task is successful...
});
从全局终端菜单执行运行任务将显示以下选择器
按下齿轮图标。这将创建以下 tasks.json 文件
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"type": "gulp",
"task": "default",
"problemMatcher": []
}
]
}
通常你现在会添加一个问题匹配器（在这种情况下是 $eslint-stylish）或修改表示设置。
使用问题匹配器处理任务输出
VS Code 可以使用问题匹配器处理任务的输出。问题匹配器会扫描任务输出文本中已知的警告或错误字符串，并在编辑器内和问题面板中内联报告这些问题。VS Code 内置了几个问题匹配器
- TypeScript:
$tsc假设输出中的文件名是相对于打开的文件夹的。 - TypeScript Watch:
$tsc-watch匹配tsc编译器在监视模式下执行时报告的问题。 - JSHint:
$jshint假设文件名以绝对路径报告。 - JSHint Stylish:
$jshint-stylish假设文件名以绝对路径报告。 - ESLint Compact:
$eslint-compact假设输出中的文件名是相对于打开的文件夹的。 - ESLint Stylish:
$eslint-stylish假设输出中的文件名是相对于打开的文件夹的。 - Go:
$go匹配go编译器报告的问题。假设文件名是相对于打开的文件夹的。 - CSharp and VB Compiler:
$mscompile假设文件名以绝对路径报告。 - Lessc compiler:
$lessc假设文件名以绝对路径报告。 - Node Sass compiler:
$node-sass假设文件名以绝对路径报告。
你也可以创建自己的问题匹配器，我们将在后面的部分讨论。
将键盘快捷键绑定到任务
如果你需要频繁运行某个任务，可以为该任务定义一个键盘快捷键。
例如，要将 Ctrl+H 绑定到上面的运行测试任务，请将以下内容添加到你的 keybindings.json 文件中
{
"key": "ctrl+h",
"command": "workbench.action.tasks.runTask",
"args": "Run tests"
}
变量替换
在编写任务配置时，拥有一组预定义的常用变量会很有用，例如活动文件 (${file}) 或工作区根文件夹 (${workspaceFolder})。VS Code 支持在 tasks.json 文件的字符串内部进行变量替换，你可以在变量参考中看到预定义变量的完整列表。
注意： 并非所有属性都接受变量替换。具体来说，只有
command、args和options支持变量替换。
下面是一个自定义任务配置的示例，它将当前打开的文件传递给 TypeScript 编译器。
{
"label": "TypeScript compile",
"type": "shell",
"command": "tsc ${file}",
"problemMatcher": ["$tsc"]
}
同样，你可以通过在名称前加上 ${config: 来引用你的项目配置设置。例如，${config:python.formatting.autopep8Path} 返回 Python 扩展设置 formatting.autopep8Path。
下面是一个自定义任务配置的示例，它使用 python.formatting.autopep8Path 设置定义的可执行文件在当前文件上执行 autopep8
{
"label": "autopep8 current file",
"type": "process",
"command": "${config:python.formatting.autopep8Path}",
"args": ["--in-place", "${file}"]
}
如果你想为 tasks.json 或 launch.json 指定 Python 扩展使用的所选 Python 解释器，可以使用 ${command:python.interpreterPath} 命令。
如果简单的变量替换还不够，你还可以通过在 tasks.json 文件中添加一个 inputs 部分来从任务用户那里获取输入。
有关 inputs 的更多信息，请参阅变量参考。
特定于操作系统的属性
任务系统支持定义特定于某个操作系统的值（例如，要执行的命令）。为此，请在 tasks.json 文件中放入一个特定于操作系统的字面量，并在该字面量内指定相应的属性。
下面是一个示例，它使用 Node.js 可执行文件作为命令，并且在 Windows 和 Linux 上的处理方式不同
{
"label": "Run Node",
"type": "process",
"windows": {
"command": "C:\\Program Files\\nodejs\\node.exe"
},
"linux": {
"command": "/usr/bin/node"
}
}
有效的操作系统属性是 windows (Windows)、linux (Linux) 和 osx (macOS)。在特定于操作系统的作用域中定义的属性会覆盖在任务或全局作用域中定义的属性。
全局任务
任务属性也可以在全局作用域中定义。如果存在，它们将用于特定的任务，除非这些任务定义了具有不同值的相同属性。在下面的示例中，有一个全局 presentation 属性，它定义了所有任务都应在新面板中执行
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"presentation": {
"panel": "new"
},
"tasks": [
{
"label": "TS - Compile current file",
"type": "shell",
"command": "tsc ${file}",
"problemMatcher": ["$tsc"]
}
]
}
提示： 要访问全局作用域的
tasks.json文件，请打开命令面板 (⇧⌘P (Windows, Linux Ctrl+Shift+P)) 并运行任务: 打开用户任务命令。
PowerShell 中的字符转义
当默认 shell 是 PowerShell 时，或者当任务被配置为使用 PowerShell 时，你可能会看到意外的空格和引号转义。意外的转义只发生在 cmdlet 上，因为 VS Code 不知道你的命令是否包含 cmdlet。下面的示例 1 显示了一个你会得到不适用于 PowerShell 的转义的情况。示例 2 显示了获得良好转义的最佳、跨平台方式。在某些情况下，你可能无法遵循示例 2，需要像示例 3 中那样手动进行转义。
"tasks": [
{
"label": "PowerShell example 1 (unexpected escaping)",
"type": "shell",
"command": "Get-ChildItem \"Folder With Spaces\""
},
{
"label": "PowerShell example 2 (expected escaping)",
"type": "shell",
"command": "Get-ChildItem",
"args": ["Folder With Spaces"]
},
{
"label": "PowerShell example 3 (manual escaping)",
"type": "shell",
"command": "& Get-ChildItem \\\"Folder With Spaces\\\""
}
]
更改任务输出的编码
任务经常与磁盘上的文件交互。如果这些文件在磁盘上存储的编码与系统编码不同，你需要让作为任务执行的命令知道要使用哪种编码。由于这取决于操作系统和使用的 shell，因此没有通用的解决方案来控制它。以下是关于如何使其工作的建议和示例。
如果你需要调整编码，你应该检查更改操作系统使用的默认编码是否有意义，或者至少通过调整 shell 的配置文件来为你使用的 shell 更改它。
如果你只需要为特定任务调整它，那么将更改编码所需的特定于操作系统的命令添加到任务命令行中。以下示例适用于 Windows，其默认代码页为 437。该任务显示一个包含西里尔字符的文件的输出，因此需要代码页 866。假设默认 shell 设置为 cmd.exe，列出该文件的任务如下所示
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "2.0.0",
"tasks": [
{
"label": "more",
"type": "shell",
"command": "chcp 866 && more russian.txt",
"problemMatcher": []
}
]
}
如果任务在 PowerShell 中执行，命令需要写成这样 chcp 866; more russian.txt。在 Linux 和 macOS 上，可以使用 locale 命令来检查区域设置并调整必要的环境变量。
任务实践示例
为了突出任务的强大功能，这里有几个 VS Code 如何使用任务来集成外部工具（如 linter 和编译器）的示例。
将 TypeScript 转译为 JavaScript
TypeScript 主题包含一个示例，该示例创建一个任务来将 TypeScript 转译为 JavaScript，并从 VS Code 内部观察任何相关的错误。
将 Less 和 SCSS 转译为 CSS
CSS 主题提供了如何使用任务生成 CSS 文件的示例。
定义一个问题匹配器
VS Code 内置了一些最常见的问题匹配器。然而，市面上有很多编译器和代码检查工具，它们都会产生自己风格的错误和警告，所以你可能想创建自己的问题匹配器。
我们有一个 helloWorld.c 程序，其中开发者将 printf 误输为 prinft。用 gcc 编译它会产生以下警告
helloWorld.c:5:3: warning: implicit declaration of function ‘prinft’
我们想创建一个问题匹配器，它可以捕获输出中的消息，并在 VS Code 中显示相应的问题。问题匹配器在很大程度上依赖于正则表达式。下面的部分假设你熟悉正则表达式。
提示： 我们发现 RegEx101 playground 是一个开发和测试正则表达式的好地方，它支持 ECMAScript (JavaScript) 风格。
一个能捕获上述警告（和错误）的匹配器如下所示
{
// The problem is owned by the cpp language service.
"owner": "cpp",
// The file name for reported problems is relative to the opened folder.
"fileLocation": ["relative", "${workspaceFolder}"],
// The name that will be shown as the source of the problem.
"source": "gcc",
// The actual pattern to match problems in the output.
"pattern": {
// The regular expression. Example to match: helloWorld.c:5:3: warning: implicit declaration of function ‘printf’ [-Wimplicit-function-declaration]
"regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
// The first match group matches the file name which is relative.
"file": 1,
// The second match group matches the line on which the problem occurred.
"line": 2,
// The third match group matches the column at which the problem occurred.
"column": 3,
// The fourth match group matches the problem's severity. Can be ignored. Then all problems are captured as errors.
"severity": 4,
// The fifth match group matches the message.
"message": 5
}
}
请注意，file、line 和 message 属性是强制性的。fileLocation 指定任务输出中产生并由问题匹配器匹配的文件路径是 absolute (绝对) 还是 relative (相对)。如果任务同时产生绝对路径和相对路径，你可以使用 autoDetect 文件位置。使用 autoDetect 时，路径首先作为绝对路径进行测试，如果文件不存在，则假定该路径是相对的。
如果模式不包含严重性，severity 会指定使用哪个问题严重性。severity 的可能值为 error、warning 或 info。
这是一个完整的 tasks.json 文件，其中包含上面的代码（注释已移除），并包装了实际的任务细节
{
"version": "2.0.0",
"tasks": [
{
"label": "build",
"command": "gcc",
"args": ["-Wall", "helloWorld.c", "-o", "helloWorld"],
"problemMatcher": {
"owner": "cpp",
"fileLocation": ["relative", "${workspaceFolder}"],
"source": "gcc",
"pattern": {
"regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
"file": 1,
"line": 2,
"column": 3,
"severity": 4,
"message": 5
}
}
}
]
}
在 VS Code 内部运行它，并按 ⇧⌘M (Windows, Linux Ctrl+Shift+M) 来获取问题列表，你会得到以下输出
注意： C/C++ 扩展包含了针对 GCC 的问题匹配器，因此我们无需定义自己的匹配器。
在模式中还可以使用一些其他属性。它们是
- location - 如果问题位置是行或行,列或起始行,起始列,结束行,结束列，那么可以使用我们的通用位置匹配组。
- endLine - 问题结束行的匹配组索引。如果编译器未提供结束行值，可以省略。
- endColumn - 问题结束列的匹配组索引。如果编译器未提供结束列值，可以省略。
- code - 问题代码的匹配组索引。如果编译器未提供代码值，可以省略。
你还可以定义一个只捕获文件的问题匹配器。为此，定义一个 pattern，并将其可选的 kind 属性设置为 file。在这种情况下，无需提供 line 或 location 属性。
注意： 如果
kind属性设置为file，一个有效的模式必须至少为file和message提供一个匹配组。如果没有提供kind属性，或者kind属性设置为location，一个有效的模式还必须提供一个line或location属性。
注意： 问题匹配器只解析给定命令的输出。如果你想解析写入到单独文件（例如日志文件）的输出，请让你运行的命令在执行结束前打印出该单独文件的内容。
定义一个多行问题匹配器
一些工具会将源文件中的问题分布在多行中，尤其是在使用 stylish 报告器时。一个例子是 ESLint；在 stylish 模式下，它会产生如下输出
test.js
1:0 error Missing "use strict" statement strict
✖ 1 problems (1 errors, 0 warnings)
我们的问题匹配器是基于行的，所以我们需要用一个正则表达式捕获文件名（test.js），再用另一个正则表达式捕获实际的问题位置和消息（1:0 error Missing "use strict" statement）。
要做到这一点，请为 pattern 属性使用一个问题模式数组。这样，你就可以为要匹配的每一行定义一个模式。
以下问题模式匹配 ESLint 在 stylish 模式下的输出——但还有一个小问题需要我们接下来解决。下面的代码有一个用于捕获文件名的第一个正则表达式，和第二个用于捕获行、列、严重性、消息和错误代码的正则表达式
{
"owner": "javascript",
"fileLocation": ["relative", "${workspaceFolder}"],
"pattern": [
{
"regexp": "^([^\\s].*)$",
"file": 1
},
{
"regexp": "^\\s+(\\d+):(\\d+)\\s+(error|warning|info)\\s+(.*)\\s\\s+(.*)$",
"line": 1,
"column": 2,
"severity": 3,
"message": 4,
"code": 5
}
]
}
然而，如果一个资源上有多个问题，这个模式将无法工作。例如，想象一下 ESLint 的以下输出
test.js
1:0 error Missing "use strict" statement strict
1:9 error foo is defined but never used no-unused-vars
2:5 error x is defined but never used no-unused-vars
2:11 error Missing semicolon semi
3:1 error "bar" is not defined no-undef
4:1 error Newline required at end of file but not found eol-last
✖ 6 problems (6 errors, 0 warnings)
该模式的第一个正则表达式将匹配 "test.js"，第二个将匹配 "1:0 error ...". 下一行 "1:9 error ..." 会被处理，但不会被第一个正则表达式匹配，因此没有问题被捕获。
为了让它正常工作，多行模式的最后一个正则表达式可以指定 loop 属性。如果设置为 true，它会指示任务系统将多行匹配器的最后一个模式应用于输出中的行，只要正则表达式匹配即可。
由第一个模式捕获的信息（在本例中匹配 `test.js`）将与每个匹配 `loop` 模式的后续行相结合，以创建多个问题。在这个例子中，将创建六个问题。
这是一个能够完全捕获 ESLint stylish 问题的匹配器
{
"owner": "javascript",
"fileLocation": ["relative", "${workspaceFolder}"],
"pattern": [
{
"regexp": "^([^\\s].*)$",
"file": 1
},
{
"regexp": "^\\s+(\\d+):(\\d+)\\s+(error|warning|info)\\s+(.*)\\s\\s+(.*)$",
"line": 1,
"column": 2,
"severity": 3,
"message": 4,
"code": 5,
"loop": true
}
]
}
注意：如果多个问题发生在同一资源的完全相同的行和列上，那么只会显示一个问题。这适用于所有问题匹配器，而不仅仅是多行问题匹配器。
修改现有的问题匹配器
如果现有的问题匹配器接近你的需求，你可以在你的 tasks.json 任务中修改它。例如，$tsc-watch 问题匹配器只适用于已关闭的文档。如果你想让它适用于所有文档，你可以这样修改它
{
"type": "npm",
"script": "watch",
"problemMatcher": {
"base": "$tsc-watch",
"applyTo": "allDocuments"
},
"isBackground": true
}
其他可修改的问题匹配器属性包括 background、fileLocation、owner、pattern、severity 和 source。
后台 / 监视任务
一些工具支持在后台运行，同时监视文件系统的变化，然后在磁盘上的文件发生变化时触发一个动作。使用 Gulp，这种功能通过 npm 模块 gulp-watch 提供。TypeScript 编译器 tsc 通过 --watch 命令行选项内置了对此的支持。
为了提供反馈，表明后台任务在 VS Code 中是活动的并正在产生问题结果，问题匹配器必须使用额外的信息来检测输出中的这些“状态”变化。让我们以 tsc 编译器为例。当编译器以监视模式启动时，它会向控制台打印以下附加信息
> tsc --watch
12:30:36 PM - Compilation complete. Watching for file changes.
当磁盘上包含问题的文件发生变化时，会出现以下输出
12:32:35 PM - File change detected. Starting incremental compilation...
src/messages.ts(276,9): error TS2304: Cannot find name 'candidate'.
12:32:35 PM - Compilation complete. Watching for file changes.
查看输出显示以下模式
- 当控制台打印出
File change detected. Starting incremental compilation...时，编译器开始运行。 - 当控制台打印出
Compilation complete. Watching for file changes.时，编译器停止。 - 在这两个字符串之间报告了问题。
- 编译器在初始启动时也会运行一次（不向控制台打印
File change detected. Starting incremental compilation...）。
为了捕获这些信息，问题匹配器可以提供一个 background 属性。
对于 tsc 编译器，一个合适的 background 属性看起来像这样
"background": {
"activeOnStart": true,
"beginsPattern": "^\\s*\\d{1,2}:\\d{1,2}:\\d{1,2}(?: AM| PM)? - File change detected\\. Starting incremental compilation\\.\\.\\.",
"endsPattern": "^\\s*\\d{1,2}:\\d{1,2}:\\d{1,2}(?: AM| PM)? - Compilation complete\\. Watching for file changes\\."
}
除了问题匹配器上的 background 属性，任务本身必须标记为 isBackground，以便任务在后台持续运行。
一个完整的为在监视模式下运行的 tsc 任务手工编写的 tasks.json 文件如下所示
{
"version": "2.0.0",
"tasks": [
{
"label": "watch",
"command": "tsc",
"args": ["--watch"],
"isBackground": true,
"problemMatcher": {
"owner": "typescript",
"fileLocation": "relative",
"pattern": {
"regexp": "^([^\\s].*)\\((\\d+|\\d+,\\d+|\\d+,\\d+,\\d+,\\d+)\\):\\s+(error|warning|info)\\s+(TS\\d+)\\s*:\\s*(.*)$",
"file": 1,
"location": 2,
"severity": 3,
"code": 4,
"message": 5
},
"background": {
"activeOnStart": true,
"beginsPattern": "^\\s*\\d{1,2}:\\d{1,2}:\\d{1,2}(?: AM| PM)? - File change detected\\. Starting incremental compilation\\.\\.\\.",
"endsPattern": "^\\s*\\d{1,2}:\\d{1,2}:\\d{1,2}(?: AM| PM)? - Compilation complete\\. Watching for file changes\\."
}
}
}
]
}
后续步骤
以上就是任务的内容 - 让我们继续...
- tasks.json 结构 - 你可以查看完整的
tasks.json结构及其描述。 - 基本编辑 - 了解功能强大的 VS Code 编辑器。
- 代码导航 - 快速浏览您的源代码。
- 语言支持 - 了解我们支持的编程语言，包括 VS Code 自带的和通过社区扩展提供的。
- 调试 - 直接在 VS Code 编辑器中调试你的源代码。
常见问题
任务可以使用的 shell 和为集成终端指定的 shell 不同吗？
可以。你可以使用 "terminal.integrated.automationProfile.*" 设置来设定将用于 VS Code 中所有自动化的 shell，这包括任务。
"terminal.integrated.automationProfile.windows": {
"path": "cmd.exe"
}
另外，你可以使用 options.shell 属性覆盖任务的 shell。你可以按任务、全局或按平台设置此项。例如，要在 Windows 上使用 cmd.exe，你的 tasks.json 将包含
{
"version": "2.0.0",
"windows": {
"options": {
"shell": {
"executable": "cmd.exe",
"args": [
"/d", "/c"
]
}
}
},
...
后台任务可以用作 launch.json 中的 prelaunchTask 吗？
可以。由于后台任务会一直运行直到被终止，一个后台任务本身没有信号表明它已经“完成”。要将后台任务用作 prelaunchTask，你必须向该后台任务添加一个合适的后台 problemMatcher，以便任务系统和调试系统有办法知道该任务“已完成”。
你的任务可以是
{
"type": "npm",
"script": "watch",
"problemMatcher": "$tsc-watch",
"isBackground": true
}
注意：
$tsc-watch是一个后台问题匹配器，这对于后台任务是必需的。
然后你可以在你的 launch.json 文件中将该任务用作 prelaunchTask
{
"name": "Launch Extension",
"type": "extensionHost",
"request": "launch",
"runtimeExecutable": "${execPath}",
"args": ["--extensionDevelopmentPath=${workspaceRoot}"],
"stopOnEntry": false,
"sourceMaps": true,
"outFiles": ["${workspaceRoot}/out/src/**/*.js"],
"preLaunchTask": "npm: watch"
}
有关后台任务的更多信息，请参阅后台 / 监视任务。
为什么我在运行任务时会收到“command not found”的错误？
当您尝试运行的任务命令未被您的终端识别为可运行的命令时，会出现“command not found”的消息。这通常是因为该命令是作为您 shell 启动脚本的一部分配置的。任务以非登录和非交互方式运行，这意味着您的 shell 的启动脚本不会被执行。特别是 nvm 就已知会使用启动脚本作为其配置的一部分。
有几种方法可以解决这个问题
- 确保您的命令在您的路径（path）上，并且不需要启动脚本来添加到您的路径中。这是解决该问题的最彻底的方法，也是推荐的解决方案。
- 您可以为您的任务进行一次性修复，使其以登录或交互方式运行。不推荐这样做，因为它可能会有其他后果。但是，对于单个任务来说，这也可以是一个快速简便的修复方法。下面是一个使用
bash作为 shell 执行此操作的任务示例
{
"type": "npm",
"script": "watch",
"options": {
"shell": {
"args": ["-c", "-l"]
}
}
}
上面的 npm 任务将带有一个命令（-c）来运行 bash，就像任务系统默认做的那样。然而，这个任务也以登录 shell（-l）的方式运行 bash。