Integration mit externen Tools über Tasks

Es gibt zahlreiche Tools zur Automatisierung von Aufgaben wie Linting, Build-Prozessen, Paketierung, Tests oder der Bereitstellung von Softwaresystemen. Beispiele hierfür sind der TypeScript-Compiler, Linter wie ESLint und TSLint sowie Build-Systeme wie Make, Ant, Gulp, Jake, Rake und MSBuild.

Diese Tools werden meist über die Kommandozeile ausgeführt und automatisieren Aufgaben innerhalb und außerhalb des Softwareentwicklungszyklus (Bearbeiten, Kompilieren, Testen und Debuggen). Aufgrund ihrer Bedeutung im Entwicklungszyklus ist es hilfreich, Tools aus VS Code heraus ausführen und deren Ergebnisse analysieren zu können. Tasks in VS Code können so konfiguriert werden, dass sie Skripte ausführen und Prozesse starten, sodass viele dieser vorhandenen Tools direkt in VS Code verwendet werden können, ohne die Kommandozeile aufrufen oder neuen Code schreiben zu müssen. Arbeitsbereichs- oder ordnerspezifische Tasks werden in der Datei tasks.json im Ordner .vscode eines Arbeitsbereichs konfiguriert.

Erweiterungen können ebenfalls Tasks über einen Task-Provider beisteuern. Diese beigesteuerten Tasks können arbeitsbereichsspezifische Konfigurationen ergänzen, die in der Datei tasks.json definiert sind.

Hinweis: Die Task-Unterstützung ist nur verfügbar, wenn Sie mit einem Arbeitsbereichsordner arbeiten. Sie ist nicht verfügbar, wenn einzelne Dateien bearbeitet werden.

TypeScript Hello World

Beginnen wir mit einem einfachen "Hello World" TypeScript-Programm, das wir in JavaScript kompilieren möchten.

Erstellen Sie einen leeren Ordner namens "mytask", generieren Sie eine tsconfig.json-Datei und starten Sie VS Code aus diesem Ordner heraus.

mkdir mytask
cd mytask
tsc --init
code .

Erstellen Sie nun eine HelloWorld.ts-Datei mit folgendem Inhalt

function sayHello(name: string): void {
  console.log(`Hello ${name}!`);
}

sayHello('Dave');

Durch Drücken von ⇧⌘B (Windows, Linux Ctrl+Shift+B) oder das Ausführen von Build-Task ausführen über das globale Terminal-Menü wird die folgende Auswahl angezeigt

Der erste Eintrag führt den TypeScript-Compiler aus und übersetzt die TypeScript-Datei in eine JavaScript-Datei. Wenn der Compiler fertig ist, sollte eine HelloWorld.js-Datei vorhanden sein. Der zweite Eintrag startet den TypeScript-Compiler im "Watch-Modus" (Überwachungsmodus). Jedes Speichern der HelloWorld.ts-Datei generiert die HelloWorld.js-Datei neu.

Sie können den TypeScript-Build- oder Watch-Task auch als Standard-Build-Task definieren, sodass er direkt ausgeführt wird, wenn Sie Build-Task ausführen (⇧⌘B (Windows, Linux Ctrl+Shift+B)) auslösen. Wählen Sie dazu im globalen Terminal-Menü Standard-Build-Task konfigurieren aus. Dies zeigt Ihnen eine Auswahl der verfügbaren Build-Tasks. Wählen Sie tsc: build oder tsc: watch, und VS Code generiert eine tasks.json-Datei. Die unten gezeigte Datei macht den tsc: build-Task zum Standard-Build-Task.

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

Das obige tasks.json-Beispiel definiert keinen neuen Task. Es weist die von der TypeScript-Erweiterung von VS Code bereitgestellten tsc: build-Tasks an, der Standard-Build-Task zu sein. Sie können den TypeScript-Compiler jetzt durch Drücken von ⇧⌘B (Windows, Linux Ctrl+Shift+B) ausführen.

Automatische Task-Erkennung

VS Code erkennt derzeit automatisch Tasks für folgende Systeme: Gulp, Grunt, Jake und npm. Wir arbeiten mit den entsprechenden Erweiterungsautoren zusammen, um auch Unterstützung für Maven und den C#-Befehl dotnet hinzuzufügen. Wenn Sie eine JavaScript-Anwendung mit Node.js als Laufzeitumgebung entwickeln, haben Sie normalerweise eine package.json-Datei, die Ihre Abhängigkeiten und die auszuführenden Skripte beschreibt. Wenn Sie das eslint-starter-Beispiel geklont haben, zeigt die Ausführung von Tasks ausführen über das globale Menü die folgende Liste

Falls noch nicht geschehen, installieren Sie die notwendigen npm-Module durch Ausführen von npm install. Öffnen Sie nun die server.js-Datei, fügen Sie am Ende einer Anweisung ein Semikolon hinzu (beachten Sie, dass der ESLint-Starter Anweisungen ohne Semikolon voraussetzt) und führen Sie erneut Tasks ausführen aus. Wählen Sie dieses Mal den Task npm: lint. Wenn Sie nach dem zu verwendenden Problem-Matcher gefragt werden, wählen Sie ESLint stylish

Das Ausführen des Tasks erzeugt einen Fehler, der in der Ansicht Probleme angezeigt wird

Zusätzlich hat VS Code eine tasks.json-Datei mit folgendem Inhalt erstellt

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

Dies weist VS Code an, die Ausgabe des npm lint-Skripts mit dem ESLint-stylish-Format auf Probleme zu untersuchen.

Für Gulp, Grunt und Jake funktioniert die automatische Task-Erkennung auf die gleiche Weise. Unten sehen Sie ein Beispiel für die erkannten Tasks für die vscode-node-debug-Erweiterung.

Tipp: Sie können Ihren Task über die Schnellöffnung (⌘P (Windows, Linux Ctrl+P)) ausführen, indem Sie 'task', ein Leerzeichen und den Befehlsnamen eingeben. In diesem Fall 'task lint'.

Die automatische Task-Erkennung kann über die folgenden Einstellungen deaktiviert werden

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

Benutzerdefinierte Tasks

Nicht alle Tasks oder Skripte können in Ihrem Arbeitsbereich automatisch erkannt werden. Manchmal ist es notwendig, eigene benutzerdefinierte Tasks zu definieren. Angenommen, Sie haben ein Skript zum Ausführen Ihrer Tests, um eine Umgebung korrekt einzurichten. Das Skript befindet sich in einem Skript-Ordner innerhalb Ihres Arbeitsbereichs und heißt test.sh für Linux und macOS sowie test.cmd für Windows. Führen Sie Tasks konfigurieren über das globale Terminal-Menü aus und wählen Sie den Eintrag tasks.json-Datei aus Vorlage erstellen. Dies öffnet die folgende Auswahl

Hinweis: Wenn Sie die Liste der Task-Runner-Vorlagen nicht sehen, haben Sie möglicherweise bereits eine tasks.json-Datei in Ihrem Ordner, deren Inhalt im Editor geöffnet wird. Schließen Sie die Datei und löschen oder benennen Sie sie für dieses Beispiel um.

Wir arbeiten an weiterer Unterstützung für die automatische Erkennung, sodass diese Liste in Zukunft immer kleiner werden wird. Da wir unseren eigenen benutzerdefinierten Task schreiben möchten, wählen Sie Andere aus der Liste. Dies öffnet die tasks.json-Datei mit einem Task-Grundgerüst. Ersetzen Sie den Inhalt durch den folgenden

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

Die Eigenschaften des Tasks haben folgende Bedeutung

• label: Die Bezeichnung des Tasks, wie sie in der Benutzeroberfläche verwendet wird.
• type: Der Typ des Tasks. Für einen benutzerdefinierten Task kann dies entweder shell oder process sein. Wenn shell angegeben ist, wird der Befehl als Shell-Befehl interpretiert (z. B. bash, cmd oder PowerShell). Wenn process angegeben ist, wird der Befehl als ein auszuführender Prozess interpretiert.
• command: Der tatsächlich auszuführende Befehl.
• windows: Alle Windows-spezifischen Eigenschaften. Diese werden anstelle der Standardeigenschaften verwendet, wenn der Befehl auf dem Windows-Betriebssystem ausgeführt wird.
• group: Definiert, zu welcher Gruppe der Task gehört. Im Beispiel gehört er zur Gruppe test. Tasks, die zur Testgruppe gehören, können durch Ausführen von Test-Task ausführen aus der Befehlspalette gestartet werden.
• presentation: Definiert, wie die Task-Ausgabe in der Benutzeroberfläche gehandhabt wird. In diesem Beispiel wird das integrierte Terminal, das die Ausgabe anzeigt, immer eingeblendet, und bei jeder Task-Ausführung wird ein neues Terminal erstellt.
• options: Überschreibt die Standardwerte für cwd (aktuelles Arbeitsverzeichnis), env (Umgebungsvariablen) oder shell (Standardshell). Optionen können pro Task, aber auch global oder pro Plattform festgelegt werden. Hier konfigurierte Umgebungsvariablen können nur innerhalb Ihres Task-Skripts oder -Prozesses referenziert werden und werden nicht aufgelöst, wenn sie Teil Ihrer Argumente, Befehle oder anderer Task-Attribute sind.
• runOptions: Definiert, wann und wie ein Task ausgeführt wird.
• hide: Versteckt den Task aus der "Task ausführen"-Schnellauswahl, was für Elemente eines zusammengesetzten Tasks nützlich sein kann, die nicht unabhängig ausführbar sind.

Sie können den vollständigen Satz an Task-Eigenschaften und Werten mit IntelliSense in Ihrer tasks.json-Datei sehen. Rufen Sie Vorschläge mit Vorschlag auslösen auf (⌃Space (Windows, Linux Ctrl+Space)) und lesen Sie die Beschreibungen beim Überfahren mit der Maus oder über das Mehr erfahren... ('i')-Flyout.

Sie können auch das tasks.json-Schema einsehen.

Shell-Befehle benötigen eine spezielle Behandlung, wenn es um Befehle und Argumente geht, die Leerzeichen oder andere Sonderzeichen wie $ enthalten. Standardmäßig unterstützt das Task-System das folgende Verhalten

• Wenn ein einzelner Befehl bereitgestellt wird, übergibt das Task-System den Befehl unverändert an die zugrunde liegende Shell. Wenn der Befehl für eine korrekte Funktion Anführungszeichen oder Escaping benötigt, muss der Befehl die entsprechenden Anführungszeichen oder Escape-Zeichen enthalten. Um beispielsweise das Verzeichnis eines Ordners aufzulisten, der Leerzeichen im Namen enthält, sollte der in Bash ausgeführte Befehl so aussehen: ls 'ordner mit leerzeichen'.

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

• Wenn ein Befehl und Argumente bereitgestellt werden, verwendet das Task-System einfache Anführungszeichen, falls der Befehl oder die Argumente Leerzeichen enthalten. Für cmd.exe werden doppelte Anführungszeichen verwendet. Ein Shell-Befehl wie der unten stehende wird in PowerShell als dir 'ordner mit leerzeichen' ausgeführt.

{
  "label": "dir",
  "type": "shell",
  "command": "dir",
  "args": ["folder with spaces"]
}

• Wenn Sie steuern möchten, wie das Argument in Anführungszeichen gesetzt wird, kann das Argument ein Literal sein, das den Wert und einen Stil für die Anführungszeichen angibt. Das folgende Beispiel verwendet Escaping anstelle von Anführungszeichen für ein Argument mit Leerzeichen.

{
  "label": "dir",
  "type": "shell",
  "command": "dir",
  "args": [
    {
      "value": "folder with spaces",
      "quoting": "escape"
    }
  ]
}

Neben Escaping werden die folgenden Werte unterstützt

• strong: Verwendet den "Strong Quoting"-Mechanismus der Shell, der alle Auswertungen innerhalb der Zeichenfolge unterdrückt. Unter PowerShell sowie für Shells unter Linux und macOS werden einfache Anführungszeichen verwendet ('). Für cmd.exe wird " verwendet.
• weak: Verwendet den "Weak Quoting"-Mechanismus der Shell, der Ausdrücke innerhalb der Zeichenfolge weiterhin auswertet (z. B. Umgebungsvariablen). Unter PowerShell sowie für Shells unter Linux und macOS werden doppelte Anführungszeichen verwendet ("). cmd.exe unterstützt kein "Weak Quoting", daher verwendet VS Code ebenfalls ".

Wenn der Befehl selbst Leerzeichen enthält, wird VS Code den Befehl standardmäßig ebenfalls "strong" in Anführungszeichen setzen. Wie bei den Argumenten kann der Benutzer die Anführungszeichen des Befehls mit demselben Literal-Stil steuern.

Es gibt weitere Task-Eigenschaften zur Konfiguration Ihres Workflows. Sie können IntelliSense mit ⌃Space (Windows, Linux Ctrl+Space) verwenden, um einen Überblick über die gültigen Eigenschaften zu erhalten.

Zusätzlich zur globalen Menüleiste können Task-Befehle über die Befehlspalette aufgerufen werden (⇧⌘P (Windows, Linux Ctrl+Shift+P)). Sie können nach 'task' filtern und die verschiedenen taskbezogenen Befehle sehen.

Zusammengesetzte Tasks

Sie können Tasks auch aus einfacheren Tasks mit der Eigenschaft dependsOn zusammensetzen. Wenn Sie beispielsweise einen Arbeitsbereich mit einem Client- und Server-Ordner haben, die beide ein Build-Skript enthalten, können Sie einen Task erstellen, der beide Build-Skripte in separaten Terminals startet. Wenn Sie mehr als einen Task in der Eigenschaft dependsOn auflisten, werden sie standardmäßig parallel ausgeführt.

Die tasks.json-Datei sieht dann so aus

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

Wenn Sie "dependsOrder": "sequence" angeben, werden Ihre Task-Abhängigkeiten in der Reihenfolge ausgeführt, in der sie in dependsOn aufgelistet sind. Alle Hintergrund-/Watch-Tasks, die in dependsOn mit "dependsOrder": "sequence" verwendet werden, müssen über einen Problem-Matcher verfügen, der nachverfolgt, wann sie "erledigt" sind. Der folgende Task führt Task Zwei, Task Drei und dann Task Eins aus.

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

Tasks auf Benutzerebene

Sie können Tasks auf Benutzerebene erstellen, die nicht an einen bestimmten Arbeitsbereich oder Ordner gebunden sind, indem Sie den Befehl Tasks: Benutzertasks öffnen verwenden. Hier können nur shell- und process-Tasks verwendet werden, da andere Task-Typen Arbeitsbereichsinformationen erfordern.

Ausgabeverhalten

Manchmal möchten Sie steuern, wie sich das Panel "Integriertes Terminal" verhält, wenn Tasks ausgeführt werden. Zum Beispiel möchten Sie vielleicht den Editor-Bereich maximieren und nur dann auf die Task-Ausgabe schauen, wenn Sie ein Problem vermuten. Das Verhalten des Terminals kann über die Eigenschaft presentation eines Tasks gesteuert werden. Sie bietet die folgenden Eigenschaften

• reveal: Steuert, ob das Panel "Integriertes Terminal" in den Vordergrund gebracht wird. Gültige Werte sind
  • always - Das Panel wird immer in den Vordergrund gebracht. Dies ist die Standardeinstellung.
  • never - Der Benutzer muss das Terminal-Panel explizit über den Befehl Ansicht > Terminal in den Vordergrund bringen (⌃` (Windows, Linux Ctrl+`)).
  • silent - Das Terminal-Panel wird nur in den Vordergrund gebracht, wenn die Ausgabe nicht auf Fehler und Warnungen untersucht wird.
• revealProblems: Steuert, ob das Problem-Panel bei der Ausführung dieses Tasks eingeblendet wird oder nicht. Hat Vorrang vor der Option reveal. Standard ist never.
  • always - Blendet bei Ausführung dieses Tasks immer das Problem-Panel ein.
  • onProblem - Blendet das Problem-Panel nur ein, wenn ein Problem gefunden wird.
  • never - Blendet bei Ausführung dieses Tasks niemals das Problem-Panel ein.
• focus: Steuert, ob das Terminal den Eingabefokus erhält oder nicht. Standard ist false.
• echo: Steuert, ob der ausgeführte Befehl im Terminal wiederholt (echoed) wird. Standard ist true.
• showReuseMessage: Steuert, ob die Meldung "Terminal wird von Tasks wiederverwendet, drücken Sie eine beliebige Taste zum Schließen" angezeigt wird.
• panel: Steuert, ob die Terminal-Instanz zwischen Task-Ausführungen geteilt wird. Mögliche Werte sind
  • shared - Das Terminal wird geteilt, und die Ausgaben anderer Task-Ausführungen werden demselben Terminal hinzugefügt.
  • dedicated - Das Terminal ist einem bestimmten Task zugewiesen. Wenn dieser Task erneut ausgeführt wird, wird das Terminal wiederverwendet. Die Ausgabe eines anderen Tasks wird jedoch in einem anderen Terminal präsentiert.
  • new - Jede Ausführung dieses Tasks verwendet ein neues, leeres Terminal.
• clear: Steuert, ob das Terminal geleert wird, bevor dieser Task ausgeführt wird. Standard ist false.
• close: Steuert, ob das Terminal, in dem der Task ausgeführt wird, geschlossen wird, wenn der Task beendet wird. Standard ist false.
• group: Steuert, ob der Task in einer bestimmten Terminalgruppe unter Verwendung von geteilten Fenstern ausgeführt wird. Tasks in derselben Gruppe (angegeben durch einen String-Wert) verwenden geteilte Terminals zur Darstellung, anstatt ein neues Terminal-Panel zu öffnen.

Sie können das Verhalten des Terminal-Panels auch für automatisch erkannte Tasks ändern. Wenn Sie beispielsweise das Ausgabeverhalten für den npm: run lint aus dem ESLint-Beispiel von oben ändern möchten, fügen Sie ihm die Eigenschaft presentation hinzu

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

Sie können auch benutzerdefinierte Tasks mit Konfigurationen für erkannte Tasks mischen. Eine tasks.json, die den npm: run lint-Task konfiguriert und einen benutzerdefinierten Test ausführen-Task hinzufügt, sieht so aus

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

Ausführungsverhalten

Sie können das Ausführungsverhalten eines Tasks über die Eigenschaft runOptions festlegen

• reevaluateOnRerun: Steuert, wie Variablen ausgewertet werden, wenn ein Task über den Befehl Letzten Task erneut ausführen ausgeführt wird. Der Standardwert ist true, was bedeutet, dass Variablen neu ausgewertet werden, wenn ein Task erneut ausgeführt wird. Wenn es auf false gesetzt ist, werden die aufgelösten Variablenwerte aus dem vorherigen Durchlauf des Tasks verwendet.
• runOn: Gibt an, wann ein Task ausgeführt wird.
  • default - Der Task wird nur ausgeführt, wenn er über den Befehl Task ausführen gestartet wird.
  • folderOpen - Der Task wird ausgeführt, wenn der enthaltende Ordner geöffnet wird. Wenn Sie zum ersten Mal einen Ordner öffnen, der einen Task mit folderOpen enthält, werden Sie gefragt, ob Tasks in diesem Ordner automatisch ausgeführt werden dürfen. Sie können Ihre Entscheidung später über den Befehl Automatische Tasks verwalten ändern und zwischen Automatische Tasks zulassen und Automatische Tasks nicht zulassen wählen.
• instanceLimit - Die Anzahl der Instanzen des Tasks, die gleichzeitig ausgeführt werden dürfen. Der Standardwert ist 1.
• instancePolicy - Bestimmt, was passiert, wenn ein Task sein instanceLimit erreicht hat. Kann gesetzt werden auf
  • prompt - Den Benutzer fragen, welche Instanz beendet werden soll (Standard).
  • silent - Keine neue Instanz starten (still).
  • terminateNewest - Die neueste laufende Instanz beenden.
  • terminateOldest - Die älteste laufende Instanz beenden.
  • warn - Keine neue Instanz starten (Warnung anzeigen).

Anpassen automatisch erkannter Tasks

Wie oben erwähnt, können Sie automatisch erkannte Tasks in der tasks.json-Datei anpassen. Normalerweise tun Sie dies, um Präsentationseigenschaften zu ändern oder einen Problem-Matcher anzuhängen, um die Ausgabe des Tasks auf Fehler und Warnungen zu scannen. Sie können einen Task direkt aus der Liste Task ausführen anpassen, indem Sie auf das Zahnradsymbol rechts klicken, um die entsprechende Task-Referenz in die tasks.json-Datei einzufügen. Angenommen, Sie haben die folgende Gulp-Datei, um JavaScript-Dateien mit ESLint zu linten (die Datei stammt von 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...
});

Das Ausführen von Task ausführen über das globale Terminal-Menü zeigt die folgende Auswahl

Klicken Sie auf das Zahnradsymbol. Dies erstellt die folgende tasks.json-Datei

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

Normalerweise würden Sie nun einen Problem-Matcher hinzufügen (in diesem Fall $eslint-stylish) oder die Präsentationseinstellungen ändern.

Verarbeitung von Task-Ausgaben mit Problem-Matchern

VS Code kann die Ausgabe eines Tasks mit einem Problem-Matcher verarbeiten. Problem-Matcher scannen den Text der Task-Ausgabe nach bekannten Warn- oder Fehlerzeichenfolgen und melden diese inline im Editor und im Panel "Probleme". VS Code liefert standardmäßig mehrere Problem-Matcher mit

• TypeScript: $tsc geht davon aus, dass Dateinamen in der Ausgabe relativ zum geöffneten Ordner sind.
• TypeScript Watch: $tsc-watch gleicht Probleme ab, die vom tsc-Compiler gemeldet werden, wenn er im Watch-Modus ausgeführt wird.
• JSHint: $jshint geht davon aus, dass Dateinamen als absoluter Pfad gemeldet werden.
• JSHint Stylish: $jshint-stylish geht davon aus, dass Dateinamen als absoluter Pfad gemeldet werden.
• ESLint Compact: $eslint-compact geht davon aus, dass Dateinamen in der Ausgabe relativ zum geöffneten Ordner sind.
• ESLint Stylish: $eslint-stylish geht davon aus, dass Dateinamen in der Ausgabe relativ zum geöffneten Ordner sind.
• Go: $go gleicht Probleme ab, die vom go-Compiler gemeldet werden. Geht davon aus, dass Dateinamen relativ zum geöffneten Ordner sind.
• CSharp and VB Compiler: $mscompile geht davon aus, dass Dateinamen als absoluter Pfad gemeldet werden.
• Lessc compiler: $lessc geht davon aus, dass Dateinamen als absoluter Pfad gemeldet werden.
• Node Sass compiler: $node-sass geht davon aus, dass Dateinamen als absoluter Pfad gemeldet werden.

Sie können auch Ihren eigenen Problem-Matcher erstellen, was wir in einem späteren Abschnitt besprechen.

Tastenkombinationen für Tasks festlegen

Wenn Sie einen Task häufig ausführen müssen, können Sie eine Tastenkombination für den Task definieren.

Um beispielsweise Ctrl+H an den oben genannten Task Tests ausführen zu binden, fügen Sie Ihrer keybindings.json-Datei Folgendes hinzu

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

Variablensubstitution

Beim Erstellen von Task-Konfigurationen ist es nützlich, eine Reihe vordefinierter häufiger Variablen wie die aktive Datei (${file}) oder den Arbeitsbereichs-Stammordner (${workspaceFolder}) zu haben. VS Code unterstützt die Variablensubstitution innerhalb von Strings in der tasks.json-Datei. Eine vollständige Liste vordefinierter Variablen finden Sie in der Variablenreferenz.

Hinweis: Nicht alle Eigenschaften akzeptieren Variablensubstitution. Insbesondere unterstützen nur command, args und options Variablensubstitution.

Unten sehen Sie ein Beispiel für eine benutzerdefinierte Task-Konfiguration, die die aktuell geöffnete Datei an den TypeScript-Compiler übergibt.

{
  "label": "TypeScript compile",
  "type": "shell",
  "command": "tsc ${file}",
  "problemMatcher": ["$tsc"]
}

Ebenso können Sie auf die Konfigurationseinstellungen Ihres Projekts verweisen, indem Sie den Namen mit ${config: voranstellen. Beispielsweise gibt ${config:python.formatting.autopep8Path} die Einstellung formatting.autopep8Path der Python-Erweiterung zurück.

Unten sehen Sie ein Beispiel für eine benutzerdefinierte Task-Konfiguration, die autopep8 auf der aktuellen Datei unter Verwendung der autopep8-Executable ausführt, die durch die Einstellung python.formatting.autopep8Path definiert ist

{
  "label": "autopep8 current file",
  "type": "process",
  "command": "${config:python.formatting.autopep8Path}",
  "args": ["--in-place", "${file}"]
}

Wenn Sie den ausgewählten Python-Interpreter angeben möchten, der von der Python-Erweiterung für tasks.json oder launch.json verwendet wird, können Sie den Befehl ${command:python.interpreterPath} verwenden.

Wenn einfache Variablensubstitution nicht ausreicht, können Sie auch Eingaben vom Benutzer Ihres Tasks erhalten, indem Sie einen inputs-Abschnitt zu Ihrer tasks.json-Datei hinzufügen.

Weitere Informationen zu inputs finden Sie in der Variablenreferenz.

Betriebssystemspezifische Eigenschaften

Das Task-System unterstützt die Definition von Werten (z. B. der auszuführende Befehl), die für ein Betriebssystem spezifisch sind. Platzieren Sie dazu ein betriebssystemspezifisches Literal in die tasks.json-Datei und geben Sie die entsprechenden Eigenschaften innerhalb dieses Literals an.

Unten sehen Sie ein Beispiel, das die Node.js-Executable als Befehl verwendet und unter Windows und Linux unterschiedlich behandelt wird

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

Gültige Betriebssystemeigenschaften sind windows für Windows, linux für Linux und osx für macOS. Eigenschaften, die in einem betriebssystemspezifischen Gültigkeitsbereich definiert sind, überschreiben Eigenschaften, die im Task- oder globalen Gültigkeitsbereich definiert sind.

Globale Tasks

Task-Eigenschaften können auch im globalen Gültigkeitsbereich definiert werden. Wenn vorhanden, werden sie für spezifische Tasks verwendet, es sei denn, diese definieren dieselbe Eigenschaft mit einem anderen Wert. Im folgenden Beispiel gibt es eine globale presentation-Eigenschaft, die festlegt, dass alle Tasks in einem neuen Panel ausgeführt werden sollen

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

Tipp: Um Zugriff auf die tasks.json-Datei im globalen Gültigkeitsbereich zu erhalten, öffnen Sie die Befehlspalette (⇧⌘P (Windows, Linux Ctrl+Shift+P)) und führen Sie den Befehl Tasks: Benutzertasks öffnen aus.

Zeichen-Escaping in PowerShell

Wenn die Standard-Shell PowerShell ist oder ein Task so konfiguriert ist, dass er PowerShell verwendet, sehen Sie möglicherweise unerwartetes Escaping von Leerzeichen und Anführungszeichen. Das unerwartete Escaping tritt nur bei Cmdlets auf, da VS Code nicht weiß, ob Ihr Befehl Cmdlets enthält. Beispiel 1 unten zeigt einen Fall, in dem Sie Escaping erhalten, das mit PowerShell nicht funktioniert. Beispiel 2 zeigt den besten, plattformübergreifenden Weg, um korrektes Escaping zu erhalten. In einigen Fällen können Sie Beispiel 2 möglicherweise nicht folgen und müssen das manuelle Escaping aus Beispiel 3 anwenden.

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

Ändern der Kodierung für eine Task-Ausgabe

Tasks arbeiten häufig mit Dateien auf der Festplatte. Wenn diese Dateien mit einer anderen Kodierung als der Systemkodierung gespeichert sind, müssen Sie dem Befehl, der als Task ausgeführt wird, mitteilen, welche Kodierung zu verwenden ist. Da dies vom Betriebssystem und der verwendeten Shell abhängt, gibt es keine allgemeine Lösung dafür. Im Folgenden finden Sie Ratschläge und Beispiele, wie dies funktionieren kann.

Wenn Sie die Kodierung anpassen müssen, sollten Sie prüfen, ob es sinnvoll ist, die Standardkodierung Ihres Betriebssystems zu ändern oder diese zumindest für die verwendete Shell durch Anpassung der Profil-Datei der Shell zu ändern.

Wenn Sie dies nur für einen bestimmten Task anpassen müssen, fügen Sie den betriebssystemspezifischen Befehl, der für die Änderung der Kodierung erforderlich ist, der Task-Befehlszeile hinzu. Das folgende Beispiel ist für Windows, das als Standard die Codepage 437 verwendet. Der Task zeigt die Ausgabe einer Datei mit kyrillischen Zeichen an und benötigt daher Codepage 866. Der Task zum Auflisten der Datei sieht wie folgt aus, unter der Annahme, dass die Standard-Shell cmd.exe ist

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

Wenn der Task in PowerShell ausgeführt wird, muss der Befehl wie folgt lauten: chcp 866; more russian.txt. Unter Linux und macOS kann der Befehl locale verwendet werden, um das Locale zu überprüfen und die notwendigen Umgebungsvariablen anzupassen.

Beispiele für Tasks in der Praxis

Um die Leistungsfähigkeit von Tasks zu unterstreichen, sind hier einige Beispiele, wie VS Code Tasks zur Integration externer Tools wie Linter und Compiler verwenden kann.

Transpilierung von TypeScript nach JavaScript

Das TypeScript-Thema enthält ein Beispiel, das einen Task zur Transpilierung von TypeScript nach JavaScript erstellt und alle damit verbundenen Fehler aus VS Code heraus beobachtet.

Transpilierung von Less und SCSS nach CSS

Das CSS-Thema bietet Beispiele für die Verwendung von Tasks zur Generierung von CSS-Dateien.

1. Manuelles Transpilieren mit einem Build-Task
2. Automatisierung des Kompilierungsschritts mit einem Datei-Watcher

Definieren eines Problem-Matchers

VS Code liefert einige der häufigsten Problem-Matcher standardmäßig mit. Es gibt jedoch unzählige Compiler- und Linting-Tools, die alle ihre eigene Art von Fehlern und Warnungen produzieren, sodass Sie möglicherweise Ihren eigenen Problem-Matcher erstellen möchten.

Wir haben ein helloWorld.c-Programm, in dem der Entwickler sich bei printf als prinft vertippt hat. Die Kompilierung mit gcc erzeugt die folgende Warnung

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

Wir möchten einen Problem-Matcher erstellen, der die Meldung in der Ausgabe erfassen und ein entsprechendes Problem in VS Code anzeigen kann. Problem-Matcher verlassen sich stark auf reguläre Ausdrücke. Der folgende Abschnitt setzt voraus, dass Sie mit regulären Ausdrücken vertraut sind.

Tipp: Wir haben festgestellt, dass der RegEx101-Spielplatz, der einen ECMAScript (JavaScript)-Flavor besitzt, eine großartige Möglichkeit ist, reguläre Ausdrücke zu entwickeln und zu testen.

Ein Matcher, der die obige Warnung (und Fehler) erfasst, sieht so aus

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

Beachten Sie, dass die Eigenschaften file, line und message obligatorisch sind. Das fileLocation gibt an, ob die Dateipfade, die von der Task-Ausgabe erzeugt und im Problem abgeglichen werden, absolut oder relativ sind. Wenn der Task sowohl absolute als auch relative Pfade erzeugt, können Sie den Speicherort autoDetect verwenden. Bei autoDetect werden Pfade zuerst als absolute Pfade getestet, und wenn die Datei nicht existiert, wird angenommen, dass der Pfad relativ ist.

Der severity gibt an, welche Problem-Schwere (Severity) verwendet werden soll, wenn das Muster keine enthält. Die möglichen Werte für severity sind error, warning oder info.

Hier ist eine fertige tasks.json-Datei mit dem obigen Code (Kommentare entfernt), verpackt mit den tatsächlichen Task-Details

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

Das Ausführen innerhalb von VS Code und das Drücken von ⇧⌘M (Windows, Linux Ctrl+Shift+M), um die Liste der Probleme zu erhalten, liefert Ihnen die folgende Ausgabe

Hinweis: Die C/C++-Erweiterung enthält Problem-Matcher für GCC, daher besteht keine Notwendigkeit, unsere eigenen zu definieren.

Es gibt noch ein paar weitere Eigenschaften, die innerhalb eines Musters verwendet werden können. Diese sind

• location - Wenn sich der Problemstandort auf line oder line,column oder startLine,startColumn,endLine,endColumn bezieht, kann unsere generische Standort-Match-Gruppe verwendet werden.
• endLine - Der Index der Match-Gruppe für die Endzeile des Problems. Kann weggelassen werden, wenn vom Compiler kein Endzeilenwert bereitgestellt wird.
• endColumn - Der Index der Match-Gruppe für die Endspalte des Problems. Kann weggelassen werden, wenn vom Compiler kein Endspaltenwert bereitgestellt wird.
• code - Der Index der Match-Gruppe für den Code des Problems. Kann weggelassen werden, wenn vom Compiler kein Codewert bereitgestellt wird.

Sie können auch einen Problem-Matcher definieren, der nur eine Datei erfasst. Definieren Sie dazu ein pattern mit dem optionalen Attribut kind, das auf file gesetzt ist. In diesem Fall ist es nicht erforderlich, eine line oder location-Eigenschaft bereitzustellen.

Hinweis: Ein funktionales Muster muss mindestens eine Match-Gruppe für file und message bereitstellen, wenn die Eigenschaft kind auf file gesetzt ist. Wenn keine kind-Eigenschaft bereitgestellt wird oder die kind-Eigenschaft auf location gesetzt ist, muss ein Funktionsmuster auch eine line- oder location-Eigenschaft bereitstellen.

Hinweis: Der Problem-Matcher analysiert nur die Ausgabe des angegebenen Befehls. Wenn Sie eine Ausgabe analysieren möchten, die in eine separate Datei geschrieben wurde (z. B. eine Protokolldatei), lassen Sie den von Ihnen ausgeführten Befehl Zeilen aus der separaten Datei ausgeben, bevor er die Ausführung beendet.

Definieren eines mehrzeiligen Problem-Matchers

Einige Tools verteilen in einer Quelldatei gefundene Probleme über mehrere Zeilen, insbesondere wenn "stylish"-Reporter verwendet werden. Ein Beispiel ist ESLint; im "stylish"-Modus erzeugt es eine Ausgabe wie diese

test.js
  1:0   error  Missing "use strict" statement                 strict
✖ 1 problems (1 errors, 0 warnings)

Unser Problem-Matcher ist zeilenbasiert, daher müssen wir den Dateinamen (test.js) mit einem anderen regulären Ausdruck erfassen als den tatsächlichen Problemort und die Meldung (1:0 error Missing "use strict" statement).

Verwenden Sie dazu ein Array von Problem-Mustern für die Eigenschaft pattern. Auf diese Weise definieren Sie ein Muster für jede Zeile, die Sie abgleichen möchten.

Hinweis: Bei einem mehrzeiligen Problem-Matcher muss jede Zeile in der Ausgabe nacheinander vom Muster-Array abgeglichen werden. Zwischenzeilen können nicht übersprungen werden, selbst wenn sie für das Erfassen von Werten nicht benötigt werden.

Das folgende Problem-Muster gleicht die Ausgabe von ESLint im "stylish"-Modus ab - hat aber noch ein kleines Problem, das wir als Nächstes lösen müssen. Der folgende Code hat einen ersten regulären Ausdruck, um den Dateinamen zu erfassen, und den zweiten, um Zeile, Spalte, Schweregrad, Meldung und Fehlercode zu erfassen

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

Dieses Muster funktioniert jedoch nicht, wenn es mehr als ein Problem für eine Ressource gibt. Stellen Sie sich zum Beispiel die folgende Ausgabe von ESLint vor

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)

Der erste reguläre Ausdruck des Musters gleicht "test.js" ab, der zweite "1:0 error ...". Die nächste Zeile "1:9 error ..." wird verarbeitet, aber nicht vom ersten regulären Ausdruck abgeglichen, sodass kein Problem erfasst wird.

Damit dies funktioniert, kann der letzte reguläre Ausdruck eines mehrzeiligen Musters die Eigenschaft loop angeben. Wenn sie auf true gesetzt ist, weist sie das Task-System an, das letzte Muster eines mehrzeiligen Matchers auf die Zeilen in der Ausgabe anzuwenden, solange der reguläre Ausdruck übereinstimmt.

Die Informationen, die vom ersten Muster erfasst wurden (das in diesem Fall test.js entspricht), werden mit jeder der nachfolgenden Zeilen kombiniert, die mit dem loop-Muster übereinstimmen, um mehrere Probleme zu erstellen. In diesem Beispiel würden sechs Probleme erstellt werden.

Hier ist ein Problem-Matcher, um ESLint-stylish-Probleme vollständig zu erfassen

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

Hinweis: Wenn Sie mehrere Probleme haben, die auf derselben Ressource mit exakt derselben Zeile und Spalte auftreten, wird nur ein Problem angezeigt. Dies gilt für alle Problem-Matcher, nicht nur für mehrzeilige Problem-Matcher.

Ändern eines bestehenden Problem-Matchers

Wenn ein bestehender Problem-Matcher nahe an dem ist, was Sie benötigen, können Sie ihn in Ihrem tasks.json-Task ändern. Zum Beispiel gilt der $tsc-watch-Problem-Matcher nur für geschlossene Dokumente. Wenn Sie möchten, dass er für alle Dokumente gilt, können Sie ihn ändern

{
  "type": "npm",
  "script": "watch",
  "problemMatcher": {
    "base": "$tsc-watch",
    "applyTo": "allDocuments"
  },
  "isBackground": true
}

Andere modifizierbare Problem-Matcher-Eigenschaften umfassen background, fileLocation, owner, pattern, severity und source.

Hintergrund- / Überwachungstasks

Einige Tools unterstützen das Ausführen im Hintergrund, während sie das Dateisystem auf Änderungen überwachen und dann eine Aktion auslösen, wenn sich eine Datei auf der Festplatte ändert. Bei Gulp wird eine solche Funktionalität durch das npm-Modul gulp-watch bereitgestellt. Der TypeScript-Compiler tsc verfügt über eine integrierte Unterstützung dafür über die Befehlszeilenoption --watch.

Um Feedback zu geben, dass ein Hintergrund-Task in VS Code aktiv ist und Problemergebnisse produziert, muss ein Problem-Matcher zusätzliche Informationen verwenden, um diese Zustandsänderungen in der Ausgabe zu erkennen. Nehmen wir den tsc-Compiler als Beispiel. Wenn der Compiler im Watch-Modus gestartet wird, gibt er die folgenden zusätzlichen Informationen auf der Konsole aus

> tsc --watch
12:30:36 PM - Compilation complete. Watching for file changes.

Wenn sich eine Datei auf der Festplatte ändert, die ein Problem enthält, erscheint die folgende Ausgabe

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.

Ein Blick auf die Ausgabe zeigt das folgende Muster

• Der Compiler läuft, wenn File change detected. Starting incremental compilation... auf die Konsole gedruckt wird.
• Der Compiler stoppt, wenn Compilation complete. Watching for file changes. auf die Konsole gedruckt wird.
• Zwischen diesen beiden Zeichenfolgen werden Probleme gemeldet.
• Der Compiler läuft auch nach dem initialen Start (ohne File change detected. Starting incremental compilation... auf die Konsole zu drucken).

Um diese Informationen zu erfassen, kann ein Problem-Matcher eine background-Eigenschaft bereitstellen.

Für den tsc-Compiler sieht eine geeignete background-Eigenschaft so aus

"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\\."
}

Zusätzlich zur background-Eigenschaft im Problem-Matcher muss der Task selbst als isBackground markiert sein, damit der Task im Hintergrund weiterläuft.

Eine vollständig handgeschriebene tasks.json für einen tsc-Task, der im Watch-Modus läuft, sieht so aus

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

Nächste Schritte

Das waren Tasks – machen wir weiter...

• tasks.json Schema – Sie können das vollständige tasks.json-Schema und Beschreibungen einsehen.
• Grundlegende Bearbeitung – Erfahren Sie mehr über den leistungsstarken VS Code-Editor.
• Code-Navigation – Schnelles Bewegen durch Ihren Quellcode.
• Sprachunterstützung – Erfahren Sie mehr über unsere unterstützten Programmiersprachen, sowohl die, die mit VS Code mitgeliefert werden, als auch die über Community-Erweiterungen.
• Debugging – Debuggen Sie Ihren Quellcode direkt im VS Code-Editor.

Häufig gestellte Fragen

Kann ein Task eine andere Shell verwenden als die für das Integrierte Terminal angegebene?

Ja. Sie können die Einstellung "terminal.integrated.automationProfile.*" verwenden, um die Shell festzulegen, die für alle Automatisierungen in VS Code verwendet wird, was auch Tasks beinhaltet.

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

Alternativ können Sie die Shell eines Tasks mit der Eigenschaft options.shell überschreiben. Sie können dies pro Task, global oder pro Plattform einstellen. Um beispielsweise cmd.exe unter Windows zu verwenden, würde Ihre tasks.json Folgendes enthalten

{
    "version": "2.0.0",
    "windows": {
        "options": {
            "shell": {
                "executable": "cmd.exe",
                "args": [
                    "/d", "/c"
                ]
            }
        }
    },
    ...

Kann ein Hintergrund-Task als prelaunchTask in der launch.json verwendet werden?

Ja. Da ein Hintergrund-Task läuft, bis er beendet wird, hat ein Hintergrund-Task von sich aus kein Signal, dass er "abgeschlossen" ist. Um einen Hintergrund-Task als prelaunchTask zu verwenden, müssen Sie dem Hintergrund-Task einen geeigneten Hintergrund-problemMatcher hinzufügen, damit das Task-System und das Debug-System wissen, dass der Task "fertig" ist.

Ihr Task könnte sein

{
  "type": "npm",
  "script": "watch",
  "problemMatcher": "$tsc-watch",
  "isBackground": true
}

Hinweis: Der $tsc-watch ist ein Hintergrund-Problem-Matcher, wie er für einen Hintergrund-Task erforderlich ist.

Sie können den Task dann als prelaunchTask in Ihrer launch.json-Datei verwenden

{
  "name": "Launch Extension",
  "type": "extensionHost",
  "request": "launch",
  "runtimeExecutable": "${execPath}",
  "args": ["--extensionDevelopmentPath=${workspaceRoot}"],
  "stopOnEntry": false,
  "sourceMaps": true,
  "outFiles": ["${workspaceRoot}/out/src/**/*.js"],
  "preLaunchTask": "npm: watch"
}

Weitere Informationen zu Hintergrund-Tasks finden Sie unter Hintergrund- / Überwachungstasks.

Warum erhalte ich beim Ausführen eines Tasks die Meldung "command not found"?

Die Meldung "command not found" tritt auf, wenn der Task-Befehl, den Sie ausführen möchten, von Ihrem Terminal nicht als ausführbar erkannt wird. Meistens passiert dies, weil der Befehl als Teil der Startskripte Ihrer Shell konfiguriert ist. Tasks werden als nicht-Login- und nicht-interaktiv ausgeführt, was bedeutet, dass die Startskripte für Ihre Shell nicht ausgeführt werden. Insbesondere von nvm ist bekannt, dass es Startskripte als Teil seiner Konfiguration verwendet.

Es gibt mehrere Möglichkeiten, dieses Problem zu lösen

1. Stellen Sie sicher, dass sich Ihr Befehl in Ihrem Pfad befindet und keine Startskripte erfordert, um Ihrem Pfad hinzugefügt zu werden. Dies ist der gründlichste Weg, das Problem zu lösen, und die empfohlene Lösung.
2. Sie können eine einmalige Korrektur für Ihren Task vornehmen, um ihn als Login- oder interaktiven Task auszuführen. Dies wird nicht empfohlen, da es andere Konsequenzen haben kann. Es kann jedoch eine schnelle und einfache Lösung für einen einzelnen Task sein. Unten sehen Sie ein Beispiel für einen Task, der dies mit bash als Shell tut

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

Der obige npm-Task wird bash mit einem Befehl (-c) ausführen, genau wie das Task-System es standardmäßig tut. Dieser Task führt bash jedoch zusätzlich als Login-Shell (-l) aus.

4/8/2026