🚀 VS Code で で入手しましょう!

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

リンティング、ビルド、パッケージング、テスト、またはソフトウェアシステムのデプロイなどのタスクを自動化するためのツールは多数存在します。例としては、TypeScript コンパイラ、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 ファイルから構成されます。

拡張機能は、タスクプロバイダーを使用してタスクを提供することもでき、これらの提供されたタスクは、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 Build Task

最初のエントリは TypeScript コンパイラを実行し、TypeScript ファイルを JavaScript ファイルに変換します。コンパイラの完了後、HelloWorld.js ファイルが存在するはずです。2 番目のエントリは、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 の例をクローンした場合、グローバルメニューから タスクの実行 を実行すると、次のリストが表示されます

Tasks ESLint starter

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

Tasks ESLint Problem Matcher Selection

タスクを実行すると、問題 ビューに 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"]
    }
  ]
}

これは、VS Code に ESLint スタイリッシュ形式を使用して npm lint スクリプトの出力を問題についてスキャンするように指示します。

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

Gulp task auto-detection

ヒント: クイックオープン (⌘P (Windows、Linux Ctrl+P)) から「task」、「Space」、およびコマンド名を入力してタスクを実行できます。この場合、「task lint」です。

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

{
  "typescript.tsc.autoDetect": "off",
  "grunt.autoDetect": "off",
  "jake.autoDetect": "off",
  "gulp.autoDetect": "off",
  "npm.autoDetect": "off"
}

カスタムタスク

すべてのタスクまたはスクリプトがワークスペースで自動検出できるわけではありません。独自のカスタムタスクを定義する必要がある場合があります。環境を正しくセットアップするためにテストを実行するスクリプトがあるとします。スクリプトはワークスペース内のスクリプトフォルダーに保存され、Linux および macOS の場合は test.sh、Windows の場合は test.cmd という名前が付けられています。グローバルな ターミナル メニューから タスクの構成 を実行し、テンプレートから tasks.json ファイルを作成 エントリを選択します。これにより、次のピッカーが開きます

Configure Task Runner

注: タスクランナーテンプレートのリストが表示されない場合は、フォルダーに 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 が指定されている場合、コマンドはシェルコマンド (例: bash、cmd、または PowerShell) として解釈されます。process が指定されている場合、コマンドは実行するプロセスとして解釈されます。
  • command: 実行する実際のコマンド。
  • windows: Windows 固有のプロパティ。コマンドが Windows オペレーティングシステムで実行される場合、デフォルトのプロパティの代わりに使用されます。
  • group: タスクが属するグループを定義します。例では、test グループに属しています。テストグループに属するタスクは、コマンドパレット から テストタスクの実行 を実行することで実行できます。
  • presentation: タスク出力がユーザーインターフェースでどのように処理されるかを定義します。この例では、出力を表示する統合ターミナルが always で表示され、タスクが実行されるたびに new ターミナルが作成されます。
  • options: cwd (現在の作業ディレクトリ)、env (環境変数)、または shell (デフォルトシェル) のデフォルトをオーバーライドします。オプションは、タスクごと、グローバルごと、またはプラットフォームごとに設定できます。ここで構成された環境変数は、タスクスクリプトまたはプロセス内からのみ参照でき、args、command、またはその他のタスク属性の一部である場合は解決されません。
  • runOptions: タスクがいつどのように実行されるかを定義します。
  • hide: 実行タスククイックピックからタスクを非表示にします。これは、独立して実行可能ではない複合タスクの要素に役立ちます。

tasks.json ファイルの IntelliSense でタスクプロパティと値の完全なセットを確認できます。候補の表示 (⌃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 はデフォルトでコマンドも強力に引用符で囲みます。引数と同様に、ユーザーは同じリテラルスタイルを使用してコマンドの引用符を制御できます。

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

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" を使用して dependsOn で使用されるバックグラウンド/監視タスクには、「完了」したタイミングを追跡する問題マッチャーが必要です。次のタスクは、タスク 2、タスク 3、そしてタスク 1 の順に実行します。

{
  "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 タスクを構成し、カスタムの テスト実行 タスクを追加する 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 ファイルに挿入します。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 および VB コンパイラ: $mscompile は、ファイル名が絶対パスとして報告されると想定しています。
  • Lessc コンパイラ: $lessc は、ファイル名が絶対パスとして報告されると想定しています。
  • Node Sass コンパイラ: $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 実行可能ファイルを使用して、現在のファイルで 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} コマンドを使用できます。

単純な変数置換だけでは不十分な場合は、inputs セクションを tasks.json ファイルに追加して、タスクのユーザーから入力を取得することもできます。

Inputs Example

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、macOS の場合は osx です。オペレーティングシステム固有のスコープで定義されたプロパティは、タスクまたはグローバルスコープで定義されたプロパティをオーバーライドします。

グローバルタスク

タスクプロパティは、グローバルスコープで定義することもできます。存在する場合、特定のタスクに使用されます。ただし、同じプロパティを異なる値で定義しない限り。以下の例では、すべてのタスクを新しいパネルで実行する必要があることを定義するグローバル 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 での文字のエスケープ

デフォルトシェルが 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 固有のコマンドをタスクコマンドラインに追加します。次の例は、デフォルトとしてコードページ 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 ファイルを生成する方法の例を提供しています。

  1. ビルドタスクを使用した手動トランスパイル
  2. ファイルウォッチャーを使用したコンパイルステップの自動化

問題マッチャーの定義

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

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) を押して問題のリストを取得すると、次の出力が得られます

GCC Problem Matcher

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

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

  • location - 問題の場所が line または line,column または startLine,startColumn,endLine,endColumn の場合、汎用的な場所一致グループを使用できます。
  • endLine - 問題の終了行の一致グループインデックス。コンパイラによって終了行の値が提供されない場合は省略できます。
  • endColumn - 問題の終了列の一致グループインデックス。コンパイラによって終了列の値が提供されない場合は省略できます。
  • code - 問題のコードに対するマッチグループインデックス。コンパイラーによってコード値が提供されない場合は省略できます。

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

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

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

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

一部のツールは、特にスタイリッシュなレポーターが使用されている場合、ソースファイルで見つかった問題を複数行にわたって分散させます。例としては、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 プロパティに問題パターン配列を使用します。これにより、一致させたい各行に対してパターンを定義します。

次の問題パターンは、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
    }
  ]
}

Note: 同じリソース上で、まったく同じ行と列で複数の問題が発生した場合、問題は 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
}

Note: $tsc-watch は、バックグラウンドタスクに必要な background 問題マッチャーです。

その後、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」メッセージは、実行しようとしているタスクコマンドが、実行可能なものとしてターミナルによって認識されない場合に発生します。最も一般的な原因は、コマンドがシェルの起動スクリプトの一部として構成されていることです。タスクは非ログインおよび非対話型として実行されるため、シェルの起動スクリプトは実行されません。特に nvm は、構成の一部として起動スクリプトを使用することが知られています。

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

  1. コマンドがパス上にあり、パスに追加するために起動スクリプトを必要としないことを確認してください。これが問題を解決する最も徹底的な方法であり、推奨される解決策です。
  2. タスクをログインまたは対話型として実行するための 1 回限りの修正を行うことができます。これは推奨されませんが、他の結果をもたらす可能性があります。ただし、単一のタスクに対する迅速かつ簡単な修正にもなります。以下は、シェルとして bash を使用してこれを行うタスクの例です。
{
  "type": "npm",
  "script": "watch",
  "options": {
    "shell": {
      "args": ["-c", "-l"]
    }
  }
}

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

04/03/2025