に参加して、VS Code の AI 支援開発について学びましょう。

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

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

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)を押すか、グローバルターミナルメニューからビルドタスクの実行を実行すると、次のピッカーが表示されます

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 stylish形式を使用してnpm lintスクリプトの出力を問題についてスキャンするように指示します。

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

Gulp task auto-detection

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

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

{
  "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 (デフォルトシェル) のデフォルトを上書きします。オプションはタスクごとに設定できますが、グローバルまたはプラットフォームごとにも設定できます。ここで設定された環境変数は、タスクスクリプトまたはプロセス内からのみ参照でき、引数、コマンド、またはその他のタスク属性の一部であっても解決されません。
  • 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はデフォルトでコマンドも強力に引用符で囲みます。引数と同様に、ユーザーは同じリテラルスタイルを使用してコマンドの引用符を制御できます。

ワークフローを構成するためのタスクプロパティは他にもあります。⌃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"でdependsOnで使用されるバックグラウンド/ウォッチタスクは、「完了」したときに追跡する問題マッチャーを持っている必要があります。次のタスクは、タスク2、タスク3、そしてタスク1を実行します。

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

ユーザーレベルのタスク

Tasks: Open User Tasksコマンドを使用して、特定のワークスペースやフォルダーに紐付けられないユーザーレベルのタスクを作成できます。他のタスクタイプはワークスペース情報を必要とするため、ここでは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を含むタスクがあるフォルダを初めて開くときに、そのフォルダでタスクを自動的に実行することを許可するかどうかを尋ねられます。後でManage Automatic Tasksコマンドを使用し、Allow Automatic TasksとDisallow Automatic Tasksの間で選択することで、決定を変更できます。
  • 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}"]
}

Python拡張機能がtasks.jsonまたはlaunch.jsonで使用する選択されたPythonインタープリターを指定したい場合は、${command:python.interpreterPath}コマンドを使用できます。

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

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)) を開き、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固有のコマンドをタスクのコマンドラインに追加します。次の例は、デフォルトがコードページ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 - 問題の場所が「行」または「行、列」または「開始行、開始列、終了行、終了列」の場合、一般的な場所マッチグループを使用できます。
  • endLine - 問題の終了行のマッチグループインデックス。コンパイラによって終了行値が提供されない場合は省略できます。
  • endColumn - 問題の終了列のマッチグループインデックス。コンパイラによって終了列値が提供されない場合は省略できます。
  • code - 問題のコードのマッチグループインデックス。コンパイラによってコード値が提供されない場合は省略できます。

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

注: kindプロパティがfileに設定されている場合、機能するパターンは少なくともfileとmessageのマッチグループを提供する必要があります。kindプロパティが提供されていない場合、または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プロパティに問題パターンの配列を使用します。このようにして、一致させたい行ごとにパターンを定義します。

次の問題パターンは、スタイリッシュモードでの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"
}

バックグラウンドタスクの詳細については、バックグラウンド / ウォッチングタスクを参照してください。

タスクを実行すると「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) としても実行します。

10/09/2025
© . This site is unofficial and not affiliated with Microsoft.