vscode 任務配置參數(shù)及任務結果分析

任務系統(tǒng)的知識體系相對復雜，今天繼續(xù)介紹任務系統(tǒng)的內(nèi)容：任務配置的更多參數(shù)以及任務結果的分析功能。

Command相關屬性和特殊處理

在自定義的任務里可以使用 command 屬性，并在這個屬性里指定我們想要運行的腳本或者程序。但是有的時候我們運行這個腳本的時候需要傳入一些參數(shù)，這時候就可以簡單地把這些參數(shù)全部寫在 command 里，比如說在運行 echo ‘Hello World’ 這樣的腳本時，我們可以把它直接放入 command 這個屬性的值中：

{
  "label": "echo",
  "type": "shell",
  "command": "echo 'Hello World'"
}

JSON

我們也可以使用一個新的屬性，叫做args。它是一個字符串的數(shù)組，在運行指定 command 的時候，args 里的每個值都會被當作其參數(shù)傳入，所以就上面的例子，我們還可以寫為：

{
 "label": "echo",
 "type": "shell",
 "command": "echo",
 "args": [
  "hello world"
 ]
}

JSON

但這里要注意的是，因為我們使用的是 JSON 來存儲這些參數(shù)，而 JSON 的數(shù)據(jù)格式并不一定能夠滿足 shell 的要求，比如不同的 shell 對空白符、$ 符之類的都有不同的解析方式，這時候就需要對這些符號進行轉義。我們可以將參數(shù)調(diào)整為下面的格式：

"args": [
        {
            "value": "Hello World",
            "quoting": "escape"
        }
]

JSON

我們可以看到，args 里的值，從一個字符串，變成一個對象。它的第一個鍵是 value 值，也就是原先的字符串，而第二個鍵 quoting 則決定了該如何處理這段字符串。

quoting在默認情況下是使用escape轉義，也就是說任務系統(tǒng)會根據(jù)我們所使用的 shell 的要求，對這段字符串進行轉義。比如說，bash 下我們使用\來轉義特殊字符，那么當我們執(zhí)行這個任務時，真正運行的腳本如下：

echo Hello\ World

Shell

從上面的代碼示例里，你可以看到空格被轉義成了 \ 。

除此之外，quoting 這個參數(shù)還有另外兩個值。第一個是 strong，那么在 bash里， 我們將會使用單引號包裹這段字符串，然后傳給腳本，那么最終執(zhí)行的腳本是：

echo 'Hello World'

Shell

另一個值是 weak，在 bash 里我們則會使用雙引號來包裹這段字符串。如：

echo "Hello World"

Shell

strong 和 weak 分別對應了 shell 不同的使用引號的策略，而bash、cmd、powershell 也都有各自的策略。如果你不熟悉，可以搜索 “quoting mechanism” 來查找，當然我們在VS Code關于 Task 參數(shù)轉義部分的文檔也有涉及。

對了，當你在 VS Code 里編輯這個 tasks.json 文件的時候是提供了自動補全和提示的，所以你可以看看它還支持什么別的屬性，也可以試著根據(jù)提示進行修改。我們在文章的最后，還會介紹幾個其他重要的屬性的。

結果分析

到這里我已經(jīng)基本把任務系統(tǒng)是如何設置的、如何運行的跟你簡單地介紹了一遍，相信你已經(jīng)可以將一些簡單的腳本用任務系統(tǒng)來執(zhí)行了。但是如果說任務系統(tǒng)只是提供一種新的運行腳本的方式，或者說幾個快捷鍵進行一鍵的腳本運行的話，那跟集成終端比只能說是往前邁了小小的一步。

不過，任務系統(tǒng)還有一個真正的威力，就是我們可以自動地去分析任務運行的結果。

任務運行的結果是由 tasks.json 里任務的一個屬性 problemMatcher 來控制的。我們可以選擇 VS Code 內(nèi)置的，或者其他插件提供的結果分析器，甚至可以自己書寫結果分析器來分析任務運行結果，然后將其中出現(xiàn)的錯誤或者警告，顯示在問題面板中。

比如說我們跑一個構建腳本，有的時候代碼寫的不對了，構建腳本就會打印出在哪個文件的第幾行有一個什么類型的錯誤，然后我們再借助合適的結果分析器，去解析相對冗余的結果日志，最后把它們?nèi)雴栴}面板中。這樣我們在書寫的過程當中，就不需要到結果日志里去找錯誤和警告了，只需要查看問題面板，點擊錯誤跳轉到代碼處，直接進行修改就可以了。

另外，如果我們在運行一些腳本的時候使用了觀察模式 （watch mode），那么每次代碼有更新，就會重新運行腳本輸出日志，這時一個實時分析日志并提供反饋的結果分析器就大大提升效率了。

VS Code 現(xiàn)在已經(jīng)自帶了以下幾種問題分析器：

• $tsc，用于分析 TypeScript 編譯的結果，$tsc-watch 則是用于分析運行在觀察模式下的 TypeScript 編譯器的結果；
• $jshint用于分析 JSHint 的結果，$jshint-stylish 用于分析JSHint Stylish的運行結果；
• $eslint-compact 和 $eslint-stylish 分別用于分析 ESLint Compact 和 ESLint Stylish；
• $go 是 Go 編譯器的分析器；
• $mscompile 用于分析 CSharp 和 VB 的編譯結果；
• $lessc 是用于分析 Lessc 的運行結果的；
• $node-sass 用于分析 Node Sass 編譯結果。

如果這些還不適用于你的項目，那你可以看看插件市場上有沒有問題分析器相關的插件Search results – problem matcher | Visual Studio Code , Visual Studio Marketplace，或者看看你使用的語言插件是否已經(jīng)支持了相對應的結果分析。

自定義問題分析器

VS Code 還支持我們自己書寫結果分析器，不過這個涉及一定的正則表達式的知識，如果你已經(jīng)有所了解，那么可以繼續(xù)看下去。如果還未有涉及，還請學習正則表達式，然后閱讀下面的示例。

首先我們將下面的配置，放入任務配置文件 tasks.json。

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "echo",
            "type": "shell",
            "command": "echo",
            "args": [
                {
                    "value": "index.js:5:3: warning: unused variable",
                    "quoting": "escape"
                }
            ],
            "problemMatcher": {
                "owner": "echo",
                "fileLocation": ["relative", "${workspaceFolder}"],
                "pattern": {
                    "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
                    "file": 1,
                    "line": 2,
                    "column": 3,
                    "severity": 4,
                    "message": 5
                }
            }
        }
    ]
}

JSON

這個示例，較之前我們介紹的示例，多一個 problemMatcher，其他都是一樣的。但是這個 problemMatcher 不再是一個字符串，而是一個對象；我們在這個對象里，自定義了如何去分析任務運行的結果。

這個任務執(zhí)行的腳本是：

echo index.js:5:3:\ warning:\ unused\ variable

Shell

在 bash 下執(zhí)行的結果如下：

index.js:5:3: warning: unused variable

這是我們通常能夠看到的構建或者測試腳本報錯時的輸出結果，我們需要從中把以下幾個信息提取出來：

• 文件地址
• 行號
• 列號
• 錯誤的重要級別
• 錯誤信息

通過文件的地址、行號和列號，我們能夠快速定位到錯誤的位置，而錯誤的級別和信息則能夠幫助我們了解錯誤的具體情況。為了把這個信息提取出來，我們將會使用正則表達式的捕獲組（group capture）。比如在我們的例子里，我們提供了一個正則表達式：

"^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$"

當我們拿這個正則表達式去匹配下面的字符串時，

index.js:5:3: warning: unused variable

捕獲組 1 對應的是文件的名字，捕獲組 2 則是行號，以此類推。然后我們通過給這個任務的 problemMatcher 設置 pattern 來告訴 VS Code，我們想使用什么樣的正則表達式去匹配，以及文件名 file、行號 line 、列 column 等該從第幾個捕獲組讀取出來。

"pattern": {
    "regexp": "^(.*):(\\d+):(\\d+):\\s+(warning|error):\\s+(.*)$",
    "file": 1,
    "line": 2,
    "column": 3,
    "severity": 4,
    "message": 5
}

JSON

除了 pattern 這個屬性，我們還需要 fileLocation 文件位置來告訴 VS Code，如何在當前文件夾下定位這個文件。比如我們從錯誤信息里得到 index.js 是一個相對的地址，然后我們通過把 fileLocation 設置為 [“relative”, “${workspaceFolder}”] 來提示 VS Code，請把 index.js當作相對地址，然后在當前文件夾下定位。

最后，當我們運行了這個任務，我們就能夠在問題面板里看到這個錯誤信息，而當我們點擊這個錯誤時，則能夠在編輯器里打開 index.js 這個文件并跳轉到第五行。

上面就是一個非?；A的問題分析器 problemMatcher 了。它能夠逐行使用正則表達式分析任務執(zhí)行的結果，并輸出給問題面板。但是如果你的任務執(zhí)行的結果里，錯誤信息橫跨多行，那么這個分析器就不起作用了。這時候你就需要一個更強大的多行結果分析器，這個我會在后面的 VS Code 高級定制章節(jié)里進一步介紹，如果你非常感興趣現(xiàn)在就想動手試一試的話，也可以閱讀Tasks in Visual Studio Code 自行學習。

多任務

很多時候，我們的項目并不只包含一種語言、一個框架，這導致我們需要同時使用多種不同的構建或者測試工具，并需要額外寫一些腳本把它們同時運行起來。不過不用擔心，VS Code 的任務系統(tǒng)也為這種情況提供了便捷的任務定制方案。比如說我們的項目里有前端和后端兩種代碼，然后我們希望同時把它們運行起來，這時我們就要首先為前、后端分別定義好各自的任務，這里我們將它們稱為 “frontend”“backend”。我們可以新建一個任務，內(nèi)容如下：

{
 "taskName": "compile",
 "dependsOn": [
  "frontend",
  "backend"
 ],
 "group": {
  "kind": "build",
  "isDefault": true
 }
}

JSON

這個任務有個新的屬性，叫做 dependsOn。它指定了“compile”這個任務依賴于 “frontend” 和 “backend” 這兩個腳本，而這個任務本身并沒有制定任何的命令 （command），同時我們還制定了這個任務為默認的生成任務（build），所以當我們按下 Cmd + Shift + B，我們就能夠看到“frontend” 和 “backend” 這兩個任務都被觸發(fā)執(zhí)行了。

通過多任務的設置，我們就真正做到一鍵運行了。不過要注意，這個功能在 VS Code 里叫做 Compound tasks ，這可能并不是一個特別好記的英文名字。

總結

以上就是我們今天的全部內(nèi)容了。VS Code 的任務系統(tǒng)，在我看來，精髓全在這個 tasks.json 的書寫，也就是說一個 JSON 對象，控制了任務的方方面面。而我只是根據(jù)我的理解和學習方式，為你做了一次梳理：

• VS Code 和一些語言相關的插件，能夠自動檢測我們本地已經(jīng)有的任務腳本配置，這樣我們就能夠直接使用任務系統(tǒng)去直接執(zhí)行它們了。你不妨看看，你的項目里正在使用的任務腳本，是否能夠被 VS Code 檢測出來？如果不能，那有沒有插件能夠做到這點呢？

• 我們可以將自動檢測出來的任務，以 tasks.json 的形式儲存在 .vscode 文件夾中，成為項目的一部分。同時，我們也可以在 tasks.json 中，對它們進行修改定制。
• 除了自動檢測，我們還能夠自己書寫自定義的任務，在書寫自定義任務配置時，有以下幾個要點：在處理腳本或者文件地址的時候，我們要非常小心。比如說在指定 command 的時候，我們使用了絕對地址，那這個地址在其他同事的機器上就不一定存在了；而如果我們使用了當前文件夾下的相對地址，或者說使用預定義變量 ${workspaceFolder}，就能很好地避免了這樣的問題。我們要考慮不同操作系統(tǒng)可能對格式有不同的要求。如果遇到了類似的問題，我們可以為某個特定的操作系統(tǒng)指定配置。我們可以指定默認的 Build 或者 Test 任務，以及使用多任務，爭取做到一鍵執(zhí)行。
• 任務結果的分析也很重要，雖然我們能夠去閱讀任務腳本的全部輸出結果，自己去查找錯誤，但是如果我們使用了合適的錯誤分析器，就能夠將錯誤和警告自動放入到問題面板中。

對一個個體而言，任務系統(tǒng)的優(yōu)勢可能還不明顯。但是如果你通過設置任務系統(tǒng)、添加錯誤分析器，把工作流程針對 VS Code 進行一次優(yōu)化，這樣你的同事在使用 VS Code 的時候，也就可以直接使用 VS Code 的任務系統(tǒng)和問題面板了，而無需為命令行腳本工具而煩惱了。

當然，你熟悉完我上面所講的那些知識點后，可能還會有更多的問題提出來，我們可以在討論區(qū)里交流。另外，我也鼓勵你自己動手調(diào)試這個文件，VS Code 為這個文件做了專門的自動補全，所以你可以通過提示來研究學習。由于篇幅所限，我可能無法將任務系統(tǒng)的每個知識點都覆蓋到，比如說任務系統(tǒng)的配置支持預定義參數(shù)，但是這個知識點我們在介紹代碼片段里涉及到了，如果你對代碼片段的預定義參數(shù)很熟悉，這個也就不陌生了。