タスクによる外部ツールとの統合

ソフトウェアシステムのリンティング、ビルド、パッケージング、テスト、デプロイなどのタスクを自動化するためのツールは数多く存在します。例として、TypeScript Compiler、ESLint や TSLint といったリンター、そして Make、Ant、Gulp、Jake、Rake、MSBuild といったビルドシステムなどが挙げられます。

VS Code can talk to a variety of external tools

これらのツールのほとんどはコマンドラインから実行され、ソフトウェア開発の内部ループ（編集、コンパイル、テスト、デバッグ）の内外でジョブを自動化します。開発ライフサイクルにおけるこれらのツールの重要性を考えると、VS Code内からツールを実行し、その結果を分析できることは有益です。VS Codeのタスクは、スクリプトの実行やプロセスの開始を行うように構成できるため、コマンドラインに入力したり新しいコードを書いたりすることなく、既存のツールの多くをVS Code内から使用できます。ワークスペースまたはフォルダー固有のタスクは、ワークスペースの .vscode フォルダーにある tasks.json ファイルで構成します。

拡張機能はタスクプロバイダー (Task Provider) を使用してタスクを提供することもでき、これらの提供されたタスクに tasks.json ファイルで定義されたワークスペース固有の構成を追加できます。

注意: タスクのサポートは、ワークスペースフォルダーで作業している場合にのみ利用可能です。単一のファイルを編集している場合には利用できません。

TypeScript Hello World

JavaScriptにコンパイルしたい、単純な「Hello World」TypeScriptプログラムから始めましょう。

空のフォルダー「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) を押すか、グローバルな ターミナル メニューから ビルドタスクの実行 (Run Build Task) を実行すると、次の選択肢が表示されます。

TypeScript Build Task

最初の項目はTypeScriptコンパイラを実行し、TypeScriptファイルをJavaScriptファイルに変換します。コンパイラが終了すると、HelloWorld.js ファイルが作成されているはずです。2番目の項目はウォッチモードでTypeScriptコンパイラを開始します。HelloWorld.ts ファイルを保存するたびに、HelloWorld.js ファイルが再生成されます。

TypeScriptのビルドタスクまたはウォッチタスクをデフォルトのビルドタスクとして定義し、ビルドタスクの実行 (⇧⌘B (Windows, Linux Ctrl+Shift+B)) をトリガーしたときに直接実行されるようにすることもできます。そのためには、グローバルな ターミナル メニューから 既定のビルドタスクの構成 (Configure Default Build Task) を選択します。利用可能なビルドタスクのリストが表示されるので、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 の例をクローンしている場合、グローバルメニューから タスクの実行 (Run Tasks) を実行すると、次のリストが表示されます。

Tasks ESLint starter

まだの場合は、npm install を実行して必要なnpmモジュールをインストールしてください。次に server.js ファイルを開き、ステートメントの末尾にセミコロンを追加します（ESLintスターターはセミコロンなしのステートメントを想定している点に注意してください）。そして再度 タスクの実行 を実行します。今回は npm: lint タスクを選択します。使用する問題マッチャーを尋ねられたら、ESLint stylish を選択します。

Tasks ESLint Problem Matcher Selection

タスクを実行すると、問題 (Problems) ビューに1つのエラーが表示されます。

Tasks ESLint Problem

さらに、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"]
    }
  ]
}

これは、npm lint スクリプトの出力をESLint stylish形式を使用してスキャンし、問題を報告するようにVS Codeに指示するものです。

Gulp、Grunt、Jakeの場合も、タスクの自動検出は同様に機能します。以下は、vscode-node-debug 拡張機能で検出されたタスクの例です。

Gulp task auto-detection

ヒント: タスクは クイックオープン (⌘P (Windows, Linux Ctrl+P)) で 'task'、Space キー、そしてコマンド名を入力することでも実行できます。この場合であれば 'task lint' と入力します。

タスクの自動検出は、以下の設定を使用して無効にできます。

{
  "js/ts.tsc.autoDetect": "off",
  "grunt.autoDetect": "off",
  "jake.autoDetect": "off",
  "gulp.autoDetect": "off",
  "npm.autoDetect": "off"
}

カスタムタスク

ワークスペース内のすべてのタスクやスクリプトが自動検出されるわけではありません。独自のカスタムタスクを定義する必要がある場合もあります。たとえば、環境を正しく設定するためにテストを実行するスクリプトがあるとします。そのスクリプトはワークスペース内のスクリプトフォルダーに保存されており、LinuxとmacOSでは test.sh、Windowsでは test.cmd という名前だとします。グローバルな ターミナル メニューから タスクの構成 (Configure Tasks) を実行し、テンプレートから tasks.json ファイルを生成 (Create tasks.json file from template) を選択します。すると、以下の選択肢が表示されます。

Configure Task Runner

注意: タスクランナーのテンプレートリストが表示されない場合は、すでにフォルダー内に tasks.json ファイルが存在し、その内容がエディターで開かれています。ファイルを閉じ、この例のために削除するか名前を変更してください。

現在、自動検出サポートの拡大に取り組んでいるため、将来的にこのリストは短くなっていくはずです。独自のカスタムタスクを作成したいので、リストから その他 (Others) を選択します。これにより、タスクのスケルトンを含む 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 が指定された場合、コマンドはシェルコマンド（bash、cmd、PowerShellなど）として解釈されます。process が指定された場合、コマンドは実行するプロセスとして解釈されます。
command: 実行する実際のコマンドです。
windows: Windows固有のプロパティです。Windows OS上でコマンドが実行される際、デフォルトのプロパティの代わりに使用されます。
group: タスクが属するグループを定義します。この例では test グループに属しています。testグループに属するタスクは、コマンドパレット から テストタスクの実行 (Run Test Task) を実行することで開始できます。
presentation: タスクの出力がユーザーインターフェイスでどのように扱われるかを定義します。この例では、出力を表示する統合ターミナルが always（常に）表示され、タスクが実行されるたびに new（新しい）ターミナルが作成されます。
options: cwd（現在の作業ディレクトリ）、env（環境変数）、または shell（デフォルトシェル）のデフォルト値をオーバーライドします。オプションはタスクごとに設定できますが、グローバルまたはプラットフォームごとに設定することも可能です。ここで構成された環境変数はタスクのスクリプトまたはプロセス内からのみ参照可能であり、引数、コマンド、その他のタスク属性の一部である場合は解決されません。
runOptions: タスクの実行タイミングと実行方法を定義します。
hide: 「タスクの実行」クイックピックからタスクを非表示にします。これは、独立して実行できない複合タスクの要素などで便利です。

tasks.json ファイル内で IntelliSense を使用すると、タスクのプロパティと値の全セットを確認できます。サジェストのトリガー (Trigger Suggest) (⌃Space (Windows, Linux Ctrl+Space)) で候補を表示し、ホバー時や 詳細... ('i') のフライアウトで説明を読むことができます。

tasks.json IntelliSense

tasks.json スキーマも確認できます。

シェルコマンドでは、スペースや $ などの特殊文字を含むコマンドや引数がある場合、特別な扱いが必要です。デフォルトで、タスクシステムは以下の動作をサポートしています。

単一のコマンドが提供された場合、タスクシステムはそのコマンドを基盤のシェルにそのまま渡します。コマンドが正しく機能するためにクォートやエスケープが必要な場合は、適切なクォートやエスケープ文字を含める必要があります。たとえば、スペースを含む名前のフォルダー内のディレクトリをリスト表示する場合、bashで実行されるコマンドは ls 'folder with spaces' のようになります。

{
  "label": "dir",
  "type": "shell",
  "command": "dir 'folder with spaces'"
}

コマンドと引数が提供された場合、コマンドや引数にスペースが含まれていれば、タスクシステムはシングルクォートを使用します。cmd.exe の場合はダブルクォートが使用されます。以下のようなシェルコマンドは、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: シェルの強いクォートメカニズムを使用し、文字列内のすべての評価を抑制します。PowerShell、およびLinux/macOS上のシェルではシングルクォート (') が使用されます。cmd.exe では " が使用されます。
weak: シェルの弱いクォートメカニズムを使用し、文字列内の式（環境変数など）を評価します。PowerShell、およびLinux/macOS上のシェルではダブルクォート (") が使用されます。cmd.exe は弱いクォートをサポートしていないため、VS Codeも " を使用します。

コマンド自体にスペースが含まれている場合、VS Codeはデフォルトでコマンドにも強力なクォートを適用します。引数と同様に、同じリテラル形式を使用してコマンドのクォートをユーザーが制御できます。

ワークフローを構成するためのタスクプロパティは他にもたくさんあります。⌃Space (Windows, Linux Ctrl+Space) で IntelliSense を使用し、有効なプロパティの概要を確認してください。

Tasks IntelliSense

グローバルメニューバーに加えて、タスクコマンドには コマンドパレット (⇧⌘P (Windows, Linux Ctrl+Shift+P)) からアクセスできます。'task' でフィルタリングすることで、さまざまなタスク関連コマンドを確認できます。

Tasks in Command Palette

複合タスク

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 にリストされている順序で実行されます。dependsOrder: sequence で使用されるバックグラウンド/ウォッチタスクには、いつ終了したかを追跡するための問題マッチャーが必要です。次のタスクは、タスクTwo、タスクThree、その次にタスクOneを実行します。

{
  "label": "One",
  "type": "shell",
  "command": "echo Hello ",
  "dependsOrder": "sequence",
  "dependsOn": ["Two", "Three"]
}

ユーザーレベルのタスク

Tasks: ユーザータスクを開く (Tasks: Open User Tasks) コマンドを使用して、特定のワークスペースやフォルダーに縛られないユーザーレベルのタスクを作成できます。他のタスクタイプはワークスペース情報を必要とするため、ここでは shell および process タスクのみを使用できます。

出力の動作

タスク実行時の統合ターミナルパネルの動作を制御したい場合があります。たとえば、エディターの領域を最大化し、問題があると思われる場合にのみタスクの出力を確認したい場合などです。ターミナルの動作はタスクの presentation プロパティを使用して制御できます。以下のプロパティが提供されています。

reveal: 統合ターミナルパネルを前面に表示するかどうかを制御します。有効な値は次の通りです。
- always - パネルを常に前面に表示します。これがデフォルトです。
- never - ユーザーが 表示 (View) > ターミナル (Terminal) コマンド (⌃` (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: 最後のタスクの再実行 (Rerun Last Task) コマンドを通じてタスクが実行されたときに、変数がどのように評価されるかを制御します。デフォルトは true で、タスクが再実行されるたびに変数が再評価されます。false に設定すると、前回のタスク実行時に解決された変数値が使用されます。
runOn: タスクの実行タイミングを指定します。
- default - タスクは タスクの実行 コマンドを通じて実行されたときのみ実行されます。
- folderOpen: 含まれているフォルダーが開かれたときにタスクが実行されます。自動タスク実行の制御方法も参照してください。
instanceLimit: 同時に実行できるタスクインスタンスの数です。デフォルト値は 1 です。
instancePolicy: タスクが instanceLimit に達したときにどうなるかを決定します。以下を設定できます。
- prompt - どのインスタンスを終了するかをユーザーに尋ねます（デフォルト）。
- silent - 新しいインスタンスを開始しません（サイレント）。
- terminateNewest - 最も新しく実行されたインスタンスを終了します。
- terminateOldest - 最も古く実行されているインスタンスを終了します。
- warn - 新しいインスタンスを開始せず、警告を表示します。

自動タスク実行の制御

task.allowAutomaticTasks VS Codeで開く VS Code Insidersで開く設定は、"runOn": "folderOpen" を持つタスクが、ワークスペースを開いたときに自動的に実行されるかどうかを制御します。自動タスクは、この設定に関係なく、信頼されていないワークスペースでは決して実行されません。

この設定は2つの値を受け入れます。

off (デフォルト): 自動タスクを実行しません。現在のワークスペースでまだ選択を行っていない場合、一度だけ 許可 (Allow) または 不許可 (Disallow) を尋ねられます。不許可 を選択（または値を明示的に off に設定）した場合、タスクは実行されず、再度プロンプトも表示されません。
on: 信頼されたワークスペースを開く際に、確認なしで常に自動タスクを実行します。

設定を行うには、ユーザー設定またはワークスペース設定に追加します。

{
  "task.allowAutomaticTasks": "off"
}

また、コマンドパレットから Tasks: 自動タスクの管理 (Tasks: Manage Automatic Tasks) コマンドを使用して、現在のワークスペースに対して 自動タスクを許可する (Allow Automatic Tasks) と 自動タスクを不許可にする (Disallow Automatic Tasks) をいつでも切り替えることができます。

自動検出されたタスクのカスタマイズ

上述の通り、tasks.json ファイル内で自動検出されたタスクをカスタマイズできます。通常は、表示プロパティを変更したり、タスクの出力をスキャンしてエラーや警告を見つけるために問題マッチャーをアタッチするために行います。タスクの実行 リストから、右側の歯車アイコンを押すことで、対応するタスク参照を tasks.json ファイルに直接挿入してカスタマイズを開始できます。ESLintを使用してJavaScriptファイルをリントするGulpファイルがあると仮定します（ファイルは 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...
});

グローバルな ターミナル メニューから タスクの実行 を実行すると、次の選択肢が表示されます。

Configure Task

歯車アイコンを押します。これにより、次の 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 は、ファイル名が絶対パスで報告されると想定します。

独自のプログラミング言語に合わせた問題マッチャーを作成することもできます。これについては後のセクションで説明します。

キーボードショートカットのタスクへの割り当て

タスクを頻繁に実行する必要がある場合は、タスクのキーボードショートカットを定義できます。

たとえば、前述の Run tests タスクに Ctrl+H をバインドするには、keybindings.json ファイルに以下を追加します。

{
  "key": "ctrl+h",
  "command": "workbench.action.tasks.runTask",
  "args": "Run tests"
}

変数の置換

タスク構成を作成する際、アクティブファイル (${file}) やワークスペースルートフォルダー (${workspaceFolder}) などの一連の定義済み共通変数を使用すると便利です。VS Codeは tasks.json ファイル内の文字列内での変数置換をサポートしており、定義済み変数の完全なリストは変数リファレンス (Variables Reference) で確認できます。

注意: すべてのプロパティが変数置換を受け入れるわけではありません。具体的には、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 実行可能ファイルを使用して、現在のファイルに対して 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 Example

inputs の詳細については、変数リファレンスを参照してください。

OS固有のプロパティ

タスクシステムは、OS固有の値（実行するコマンドなど）の定義をサポートしています。そのためには、tasks.json ファイルにOS固有のリテラルを配置し、そのリテラル内に対応するプロパティを指定します。

以下は、Node.js 実行可能ファイルをコマンドとして使用し、WindowsとLinuxで異なる扱いをする例です。

{
  "label": "Run Node",
  "type": "process",
  "windows": {
    "command": "C:\\Program Files\\nodejs\\node.exe"
  },
  "linux": {
    "command": "/usr/bin/node"
  }
}

有効なOSプロパティは、Windows用の windows、Linux用の linux、macOS用の osx です。OS固有のスコープで定義されたプロパティは、タスクスコープまたはグローバルスコープで定義されたプロパティをオーバーライドします。

グローバルタスク

タスクプロパティはグローバルスコープで定義することもできます。存在する場合、異なる値を持つ同じプロパティが個別のタスクで定義されない限り、そのプロパティが使用されます。以下の例では、すべてのタスクを新しいパネルで実行するように定義するグローバルな 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)) を開き、Tasks: ユーザータスクを開く (Tasks: Open User Tasks) コマンドを実行します。

PowerShellでの文字エスケープ

デフォルトシェルが PowerShell の場合、またはタスクが PowerShell を使用するように構成されている場合、予期しないスペースやクォートのエスケープが発生することがあります。予期しないエスケープは、VS Codeがコマンドにコマンドレットが含まれているかどうかを判断できないため、コマンドレットでのみ発生します。以下の例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\\\""
    }
]

タスク出力のエンコーディング変更

タスクは頻繁にディスク上のファイルを操作します。これらのファイルがシステムエンコーディングとは異なるエンコーディングでディスクに保存されている場合、タスクとして実行されるコマンドにどのエンコーディングを使用するかを知らせる必要があります。これはOSや使用するシェルに依存するため、これを制御するための一般的な解決策はありません。以下に、それを機能させるためのアドバイスと例を示します。

エンコーディングを微調整する必要がある場合は、OSが使用するデフォルトのエンコーディングを変更するのが適切か、あるいはシェルのプロファイルファイルを微調整して使用するシェルだけでも変更できるかを確認してください。

特定のタスクだけで調整が必要な場合は、OS固有のコマンドをタスクのコマンドラインに追加してエンコーディングを変更します。次の例は、デフォルトのコードページが437であるWindowsの場合です。タスクはキリル文字を含むファイルの出力を表示するため、コードページ866が必要です。デフォルトシェルが 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がタスクを使用してリンターやコンパイラなどの外部ツールを統合する方法の例をいくつか紹介します。

TypeScriptからJavaScriptへのトランスパイル
TypeScriptトピックには、TypeScriptをJavaScriptにトランスパイルし、関連するエラーをVS Code内から監視するためのタスクを作成する例が含まれています。

LessおよびSCSSからCSSへのトランスパイル

CSSトピックでは、タスクを使用してCSSファイルを生成する方法の例を提供しています。

ビルドタスクによる手動トランスパイル

ファイルウォッチャーによるコンパイルステップの自動化

問題マッチャーの定義

VS Codeには、最も一般的な問題マッチャーのいくつかが「箱から出してすぐに使える」状態で付属しています。しかし、世の中には多くのコンパイラやリンティングツールが存在し、それぞれ独自のスタイルでエラーや警告を生成するため、独自のプログラミング言語に合わせた問題マッチャーを作成したい場合があるでしょう。

開発者が printf を prinft と打ち間違えた helloWorld.c プログラムがあるとします。gcc でコンパイルすると、次の警告が生成されます。

helloWorld.c:5:3: warning: implicit declaration of function ‘prinft’

出力内のメッセージをキャプチャし、VS Codeで対応する問題を表示する問題マッチャーを作成したいと思います。問題マッチャーは正規表現に大きく依存しています。以下のセクションでは、正規表現に精通していることを前提としています。

ヒント: ECMAScript (JavaScript) フレーバーを持つ RegEx101 プレイグラウンドは、正規表現の開発とテストに非常に役立つことがわかりました。

上記の警告（およびエラー）をキャプチャするマッチャーは次のようになります。

{
  // 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
  }
}

ファイル、行、メッセージのプロパティは必須であることに注意してください。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) を押して問題リストを取得すると、次の出力が得られます。

GCC Problem Matcher

注意: C/C++ 拡張機能にはGCC用の問題マッチャーが含まれているため、独自に定義する必要はありません。

パターン内で使用できるプロパティは他にもいくつかあります。これらは次の通りです。

location - 問題の場所が「行」または「行,列」または「開始行,開始列,終了行,終了列」である場合、汎用的な場所一致グループを使用できます。
endLine - 問題の終了行のキャプチャグループインデックスです。コンパイラから終了行の値が提供されない場合は省略できます。
endColumn - 問題の終了列のキャプチャグループインデックスです。コンパイラから終了列の値が提供されない場合は省略できます。
code - 問題コードのキャプチャグループインデックスです。コンパイラからコードが提供されない場合は省略できます。

ファイルのみをキャプチャする問題マッチャーを定義することもできます。そのためには、kind 属性が file に設定されたオプションの pattern を定義します。この場合、line や location プロパティを提供する必要はありません。

注意: kind プロパティが file に設定されている場合、機能的なパターンは少なくとも file と message のキャプチャグループを提供する必要があります。kind プロパティが提供されていないか、または location に設定されている場合、関数パターンは line または location プロパティも提供する必要があります。

注意: 問題マッチャーは指定されたコマンドからの出力のみを解析します。個別のファイル（ログファイルなど）に書き込まれた出力を解析したい場合は、実行が終了する前に、個別のファイルから行を出力するようにコマンドを設定してください。

複数行の問題マッチャーの定義

一部のツールは、ソースファイルで見つかった問題を複数の行に分散させます。特にスタイリッシュなレポーターが使用される場合に顕著です。例として ESLint があり、スタイリッシュモードでは次のような出力を生成します。

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 プロパティに問題パターンの配列を使用します。このようにして、一致させたい各行に対してパターンを定義します。

注意: 複数行の問題マッチャーでは、パターン配列は最初のパターンから順に、連続する出力行と一致する必要があります。情報が不要な行であっても、中間行をスキップすることはできません。

ツールが3行出力し、最初と3番目の行からのデータのみが必要な場合でも、パターン配列には3つのエントリが必要です。データが不要な行には、キャプチャグループ割り当てのない {"regexp": "^.*$"} を使用してください。

"pattern": [
    { "regexp": "^Error:\\s+(.*)$", "message": 1 },
    { "regexp": "^.*$" },
    { "regexp": "^\\s+at\\s+(.*):(\\d+)$", "file": 1, "line": 2 }
]

以下の問題パターンは、ESLintのスタイリッシュモードからの出力と一致しますが、次に解決する必要がある小さな問題が1つ残っています。以下のコードは、最初の正規表現でファイル名をキャプチャし、2番目の正規表現で「行、列、重大度、メッセージ、エラーコード」をキャプチャするものです。

{
  "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" に一致し、2番目は "1:0 error ..." に一致します。次の行 "1:9 error ..." は処理されますが、最初の正規表現とは一致しないため、問題はキャプチャされません。

これを機能させるには、複数行パターンの最後の正規表現に loop プロパティを指定できます。true に設定すると、正規表現が一致する限り、複数行マッチャーの最後のパターンを出力行に適用するようにタスクシステムに指示します。

最初のパターンによってキャプチャされた情報（この場合は test.js に一致）は、loop パターンと一致する後続の各行と組み合わされ、複数の問題が作成されます。この例では、6つの問題が作成されます。

ESLintのスタイリッシュな問題を完全にキャプチャする問題マッチャーは次の通りです。

{
  "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
    }
  ]
}

注意: 同じリソース上で、まったく同じ行と列に複数の問題が発生している場合、表示される問題は1つだけです。これは複数行の問題マッチャーだけでなく、すべての問題マッチャーに適用されます。

既存の問題マッチャーの修正

既存の問題マッチャーが必要なものに近い場合は、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でアクティブであり、問題の結果を生成しているというフィードバックを提供するには、問題マッチャーが出力内のこれらの state 変化を検出するために追加情報を使用する必要があります。例として 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. がコンソールに表示されると、コンパイラは停止します。
その2つの文字列の間で問題が報告されます。
コンパイラは最初の開始時にも一度実行されます（コンソールに 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エディター内でソースコードを直接デバッグします。

よくある質問

タスクは統合ターミナルに指定されたものとは異なるシェルを使用できますか？

はい。"terminal.integrated.automationProfile.*" 設定を使用して、タスクを含むVS Code内のすべての自動化に使用されるシェルを設定できます。

    "terminal.integrated.automationProfile.windows": {
        "path": "cmd.exe"
    }

あるいは、options.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"
}

バックグラウンドタスクの詳細については、バックグラウンド / ウォッチタスクに進んでください。

タスクを実行するときに「コマンドが見つかりません」というエラーが出るのはなぜですか？

「コマンドが見つかりません」というメッセージは、実行しようとしているタスクコマンドがターミナルで実行可能なものとして認識されていない場合に発生します。これは、コマンドがシェルのスタートアップスクリプトの一部として構成されている場合に最もよく発生します。タスクは非ログインかつ非対話型として実行されるため、シェルのスタートアップスクリプトは実行されません。特に nvm は、構成の一部としてスタートアップスクリプトを使用することで知られています。

この問題を解決するにはいくつかの方法があります。

コマンドがパス上にあり、パスに追加するためにスタートアップスクリプトを必要としないことを確認してください。これが問題を解決するための最も徹底的かつ推奨される方法です。
タスクがログインシェルまたは対話型シェルとして実行されるように、一度限りの修正を行うことができます。これには他の影響を及ぼす可能性があるため推奨されませんが、単一のタスクに対する簡単で迅速な修正になる可能性があります。以下は、bash をシェルとして使用してこれを行うタスクの例です。

{
  "type": "npm",
  "script": "watch",
  "options": {
    "shell": {
      "args": ["-c", "-l"]
    }
  }
}

上記の npm タスクは、タスクシステムがデフォルトで行うのと同様に、コマンド (-c) を付けて bash を実行します。ただし、このタスクは bash をログインシェル (-l) としても実行します。

5/28/2026