ist jetzt verfügbar! Lesen Sie über die neuen Funktionen und Fehlerbehebungen vom November.

Integration mit externen Tools über Tasks

Es gibt viele Tools zur Automatisierung von Aufgaben wie Linting, Erstellen, Verpacken, Testen oder Bereitstellen 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.

VS Code can talk to a variety of external tools

Diese Tools werden meist über die Befehlszeile ausgeführt und automatisieren Jobs innerhalb und außerhalb der internen Softwareentwicklungs-Schleife (Bearbeiten, Kompilieren, Testen und Debuggen). Angesichts ihrer Bedeutung im Entwicklungszyklus ist es hilfreich, Tools auszuführen und ihre Ergebnisse innerhalb von VS Code zu analysieren. Arbeitsbereichs- oder Ordnerspezifische Tasks werden aus der Datei tasks.json im Ordner .vscode für einen Arbeitsbereich konfiguriert.

Erweiterungen können auch Tasks über einen Task Provider beisteuern, und diese beigesteuerten Tasks können arbeitsbereichsspezifische Konfigurationen hinzufügen, die in der Datei tasks.json definiert sind.

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

TypeScript Hello World

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

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

mkdir mytask
cd mytask
tsc --init
code .

Erstellen Sie nun eine Datei HelloWorld.ts mit folgendem Inhalt

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

sayHello('Dave');

Wenn Sie ⇧⌘B (Windows, Linux Ctrl+Shift+B) drücken oder Build Task ausführen aus dem globalen Menü Terminal aufrufen, wird der folgende Picker angezeigt

TypeScript Build Task

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 Datei HelloWorld.js vorhanden sein. Der zweite Eintrag startet den TypeScript-Compiler im Watch-Modus. Jedes Speichern der Datei HelloWorld.ts generiert die Datei HelloWorld.js neu.

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

{
  // 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 annotiert die von der TypeScript-Erweiterung von VS Code bereitgestellten Tasks tsc: build als Standard-Build-Task. Sie können nun den TypeScript-Compiler ausführen, indem Sie ⇧⌘B (Windows, Linux Ctrl+Shift+B) drücken.

Automatische Erkennung von Tasks

VS Code erkennt derzeit Tasks für die folgenden Systeme automatisch: Gulp, Grunt, Jake und npm. Wir arbeiten mit den entsprechenden Erweiterungsautoren zusammen, um Unterstützung für Maven und das C#-dotnet-Kommando hinzuzufügen. Wenn Sie eine JavaScript-Anwendung mit Node.js als Laufzeitumgebung entwickeln, haben Sie normalerweise eine Datei package.json, 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 aus dem globalen Menü die folgende Liste an

Tasks ESLint starter

Wenn Sie dies noch nicht getan haben, installieren Sie die erforderlichen npm-Module, indem Sie npm install ausführen. Öffnen Sie nun die Datei server.js und fügen Sie am Ende einer Anweisung einen Semikolon hinzu (beachten Sie, dass der ESLint-Starter Anweisungen ohne Semikolon annimmt) und führen Sie Tasks ausführen erneut aus. Wählen Sie diesmal den Task npm: lint. Wenn Sie nach dem Problem-Matcher gefragt werden, wählen Sie ESLint stylish

Tasks ESLint Problem Matcher Selection

Die Ausführung des Tasks erzeugt einen Fehler, der in der Ansicht Probleme angezeigt wird

Tasks ESLint Problem

Zusätzlich hat VS Code eine Datei tasks.json 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 Skripts npm lint mit dem ESLint-Stilformat auf Probleme zu scannen.

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

Gulp task auto-detection

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

Die automatische Task-Erkennung kann mit den folgenden Einstellungen deaktiviert werden

{
  "typescript.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 bestimmte Umgebung korrekt einzurichten. Das Skript ist in einem Skriptordner in Ihrem Arbeitsbereich gespeichert und heißt test.sh für Linux und macOS und test.cmd für Windows. Führen Sie Tasks konfigurieren aus dem globalen Menü Terminal aus und wählen Sie den Eintrag tasks.json-Datei aus Vorlage erstellen. Dies öffnet den folgenden Picker

Configure Task Runner

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

Wir arbeiten an weiterer automatischer Erkennung, sodass diese Liste in Zukunft immer kleiner wird. Da wir unseren eigenen benutzerdefinierten Task schreiben möchten, wählen Sie Andere aus der Liste. Dies öffnet die Datei tasks.json mit einem Task-Skelett. Ersetzen Sie den Inhalt durch Folgendes

{
  // 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 die folgende Semantik

  • label: Die Task-Beschriftung, die in der Benutzeroberfläche verwendet wird.
  • type: Der Task-Typ. 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 auszuführender Prozess interpretiert.
  • command: Der eigentliche auszuführende Befehl.
  • windows: Alle Windows-spezifischen Eigenschaften. Werden anstelle der Standardeigenschaften verwendet, wenn der Befehl unter dem Betriebssystem Windows 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 ausgeführt werden.
  • presentation: Definiert, wie die Task-Ausgabe in der Benutzeroberfläche behandelt wird. In diesem Beispiel wird das integrierte Terminal, das die Ausgabe anzeigt, immer angezeigt und bei jeder Task-Ausführung ein neues Terminal erstellt.
  • options: Überschreibt die Standardwerte für cwd (aktuelles Arbeitsverzeichnis), env (Umgebungsvariablen) oder shell (Standard-Shell). Optionen können pro Task, aber auch global oder pro Plattform festgelegt werden. Hier konfigurierte Umgebungsvariablen können nur aus Ihrem Task-Skript oder -Prozess referenziert werden und werden nicht aufgelöst, wenn sie Teil Ihrer Argumente, Ihres Befehls oder anderer Task-Attribute sind.
  • runOptions: Definiert, wann und wie ein Task ausgeführt wird.
  • hide: Verbirgt den Task vor dem Schnellzugriff zum Ausführen von Tasks, was für Elemente eines zusammengesetzten Tasks, die nicht eigenständig ausführbar sind, nützlich sein kann.

Sie können den vollständigen Satz von Task-Eigenschaften und -Werten mit IntelliSense in Ihrer Datei tasks.json sehen. Rufen Sie Vorschläge mit Vorschlag auslösen (⌃Space (Windows, Linux Ctrl+Space)) auf und lesen Sie die Beschreibungen im Hover oder mit dem Pop-up Mehr erfahren... ('i').

tasks.json IntelliSense

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

Shell-Befehle erfordern eine besondere 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 angegeben wird, übergibt das Task-System den Befehl unverändert an die zugrunde liegende Shell. Wenn der Befehl Anführungszeichen oder Escape-Zeichen benötigt, um ordnungsgemäß zu funktionieren, muss der Befehl die entsprechenden Anführungszeichen oder Escape-Zeichen enthalten. Um beispielsweise das Verzeichnis eines Ordners mit Leerzeichen im Namen aufzulisten, sollte der in bash ausgeführte Befehl wie folgt aussehen: ls 'Ordner mit Leerzeichen'.
{
  "label": "dir",
  "type": "shell",
  "command": "dir 'folder with spaces'"
}
  • Wenn ein Befehl und Argumente angegeben werden, verwendet das Task-System einfache Anführungszeichen, wenn der Befehl oder die Argumente Leerzeichen enthalten. Für cmd.exe werden doppelte Anführungszeichen verwendet. Ein Shell-Befehl wie der folgende 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 maskiert wird, kann das Argument ein Literal sein, das den Wert und einen Maskierungsstil angibt. Das folgende Beispiel verwendet Maskierung anstelle von Maskierung für ein Argument mit Leerzeichen.
{
  "label": "dir",
  "type": "shell",
  "command": "dir",
  "args": [
    {
      "value": "folder with spaces",
      "quoting": "escape"
    }
  ]
}

Neben der Maskierung sind die folgenden Werte zulässig

  • strong: Verwendet den starken Maskierungsmechanismus der Shell, der alle Auswertungen innerhalb der Zeichenkette unterdrückt. Unter PowerShell und für Shells unter Linux und macOS werden einfache Anführungszeichen (') verwendet. Für cmd.exe wird " verwendet.
  • weak: Verwendet den schwachen Maskierungsmechanismus der Shell, der Ausdrücke innerhalb der Zeichenkette immer noch auswertet (z. B. Umgebungsvariablen). Unter PowerShell und für Shells unter Linux und macOS werden doppelte Anführungszeichen (") verwendet. cmd.exe unterstützt keine schwache Maskierung, daher verwendet VS Code ebenfalls ".

Wenn der Befehl selbst Leerzeichen enthält, maskiert VS Code den Befehl standardmäßig ebenfalls mit starken Anführungszeichen. Wie bei den Argumenten kann der Benutzer die Maskierung des Befehls mit demselben Literalstil steuern.

Es gibt weitere Task-Eigenschaften, um Ihren Workflow zu konfigurieren. Sie können IntelliSense mit ⌃Space (Windows, Linux Ctrl+Space) verwenden, um eine Übersicht über die gültigen Eigenschaften zu erhalten.

Tasks IntelliSense

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

Tasks in Command Palette

Zusammengesetzte Tasks

Sie können Tasks auch aus einfacheren Tasks mit der Eigenschaft dependsOn zusammensetzen. Wenn Sie beispielsweise einen Arbeitsbereich mit einem Client- und einem Serverordner haben und 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 diese standardmäßig parallel ausgeführt.

Die Datei tasks.json sieht 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 aufgeführt sind. Hintergrund-/Watch-Tasks, die in dependsOn mit "dependsOrder": "sequence" verwendet werden, müssen einen Problem-Matcher haben, der verfolgt, wann sie "fertig" 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"]
}

Benutzerebene Tasks

Sie können Tasks auf Benutzerebene erstellen, die nicht an einen bestimmten Arbeitsbereich oder Ordner gebunden sind, indem Sie den Befehl Tasks: Benutzerdefinierte Tasks ö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 das integrierte Terminalfenster beim Ausführen von Tasks verhalten wird. Sie möchten beispielsweise den Editorplatz maximieren und die Task-Ausgabe nur dann betrachten, wenn Sie ein Problem vermuten. Das Verhalten des Terminals kann mit der Eigenschaft presentation eines Tasks gesteuert werden. Sie bietet die folgenden Eigenschaften

  • reveal: Steuert, ob das integrierte Terminalfenster nach vorne gebracht wird. Gültige Werte sind
    • always - Das Fenster wird immer nach vorne gebracht. Dies ist der Standardwert.
    • never - Der Benutzer muss das Terminalfenster explizit mit dem Befehl Anzeigen > Terminal (⌃` (Windows, Linux Ctrl+`)) nach vorne bringen.
    • silent - Das Terminalfenster wird nur dann nach vorne gebracht, wenn die Ausgabe nicht auf Fehler und Warnungen überprüft wird.
  • revealProblems: Steuert, ob das Fenster "Probleme" beim Ausführen dieses Tasks angezeigt wird oder nicht. Hat Vorrang vor der Option reveal. Standard ist never.
    • always - Das Fenster "Probleme" wird immer angezeigt, wenn dieser Task ausgeführt wird.
    • onProblem - Das Fenster "Probleme" wird nur angezeigt, wenn ein Problem gefunden wird.
    • never - Das Fenster "Probleme" wird niemals angezeigt, wenn dieser Task ausgeführt wird.
  • focus: Steuert, ob das Terminal den Eingabefokus erhält oder nicht. Standard ist false.
  • echo: Steuert, ob der ausgeführte Befehl im Terminal angezeigt wird. Standard ist true.
  • showReuseMessage: Steuert, ob die Meldung "Terminal wird von Tasks wiederverwendet, drücken Sie eine beliebige Taste, um es zu schließen" angezeigt wird.
  • panel: Steuert, ob die Terminalinstanz zwischen Task-Ausführungen geteilt wird. Mögliche Werte sind
    • shared - Das Terminal wird geteilt und die Ausgaben anderer Task-Ausführungen werden zum selben Terminal hinzugefügt.
    • dedicated - Das Terminal ist einem bestimmten Task zugeordnet. Wenn dieser Task erneut ausgeführt wird, wird das Terminal wiederverwendet. Die Ausgabe eines anderen Tasks wird jedoch in einem anderen Terminal angezeigt.
    • new - Jede Ausführung dieses Tasks verwendet ein neues, leeres Terminal.
  • clear: Steuert, ob das Terminal vor der Ausführung dieses Tasks gelöscht wird. Standard ist false.
  • close: Steuert, ob das Terminal, in dem der Task ausgeführt wird, nach Beendigung des Tasks geschlossen wird. Standard ist false.
  • group: Steuert, ob der Task in einer bestimmten Terminalgruppe unter Verwendung von Split-Panels ausgeführt wird. Tasks in derselben Gruppe (angegeben durch einen String-Wert) verwenden Split-Terminals anstelle eines neuen Terminalpanels.

Sie können das Verhalten des Terminalpanels auch für automatisch erkannte Tasks ändern. Wenn Sie beispielsweise das Ausgabeverhalten für npm: run lint aus dem ESLint-Beispiel von oben ändern möchten, fügen Sie 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-Datei, die den Task npm: run lint konfiguriert und einen benutzerdefinierten Task Run Test 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 die Ausführungsverhalten eines Tasks mit der 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 auf false gesetzt, werden die aufgelösten Variablenwerte aus der vorherigen Ausführung 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 ausgeführt wird.
    • folderOpen - Der Task wird ausgeführt, wenn der enthaltende Ordner geöffnet wird. Beim ersten Öffnen eines Ordners, der einen Task mit folderOpen enthält, werden Sie gefragt, ob Sie zulassen möchten, dass Tasks in diesem Ordner automatisch ausgeführt werden. Sie können Ihre Entscheidung später über den Befehl Automatische Tasks verwalten ändern und zwischen Automatische Tasks zulassen und Automatische Tasks ablehnen wählen.
  • instanceLimit - Die Anzahl der gleichzeitig zulässigen Instanzen des Tasks. Der Standardwert ist 1.

Anpassen automatisch erkannter Tasks

Wie oben erwähnt, können Sie automatisch erkannte Tasks in der Datei tasks.json anpassen. Dies tun Sie normalerweise, um Präsentationseigenschaften zu ändern oder einen Problem-Matcher anzufügen, um die Task-Ausgabe 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 den entsprechenden Task-Verweis in die Datei tasks.json einzufügen. Angenommen, Sie haben die folgende Gulp-Datei zum Linting von JavaScript-Dateien mit ESLint (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...
});

Die Ausführung von Task ausführen aus dem globalen Menü Terminal zeigt den folgenden Picker an

Configure Task

Drücken Sie das Zahnradsymbol. Dies erstellt die folgende Datei 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": []
    }
  ]
}

Normalerweise würden Sie jetzt 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 Warnungs- oder Fehlermeldungen und melden diese inline im Editor und in der Probleme-Ansicht. VS Code wird mit mehreren Problem-Matchern "eingebaut" geliefert

  • TypeScript: $tsc geht davon aus, dass Dateinamen in der Ausgabe relativ zum geöffneten Ordner sind.
  • TypeScript Watch: $tsc-watch findet Probleme, die vom tsc-Compiler im Watch-Modus gemeldet werden.
  • 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 findet Probleme, die vom go-Compiler gemeldet werden. Geht davon aus, dass Dateinamen relativ zum geöffneten Ordner sind.
  • CSharp und 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, den wir in einem späteren Abschnitt besprechen werden.

Tastenkombinationen Tasks zuweisen

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

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

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

Variablenersetzung

Beim Erstellen von Task-Konfigurationen ist es nützlich, einen Satz vordefinierter allgemeiner Variablen zu haben, wie die aktive Datei (${file}) oder den Arbeitsbereich-Stammordner (${workspaceFolder}). VS Code unterstützt die Variablenersetzung in Zeichenketten in der Datei tasks.json, und Sie können eine vollständige Liste der vordefinierten Variablen in der Variablenreferenz finden.

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

Unten ist 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"]
}

Ähnlich können Sie auf die Konfigurationseinstellungen Ihres Projekts verweisen, indem Sie den Namen mit ${config: voranstellen. Zum Beispiel gibt ${config:python.formatting.autopep8Path} die Python-Erweiterungseinstellung formatting.autopep8Path zurück.

Unten ist ein Beispiel für eine benutzerdefinierte Task-Konfiguration, die autopep8 auf der aktuellen Datei ausführt und die von der Einstellung python.formatting.autopep8Path definierte autopep8-ausführbare Datei verwendet

{
  "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 eine einfache Variablenersetzung nicht ausreicht, können Sie auch Eingaben vom Benutzer Ihres Tasks erhalten, indem Sie einen inputs-Abschnitt zu Ihrer tasks.json-Datei hinzufügen.

Inputs Example

Weitere Informationen zu inputs finden Sie in der Variablenreferenz.

Betriebssystemspezifische Eigenschaften

Das Task-System unterstützt die Definition von werten (z. B. des auszuführenden Befehls), die für ein Betriebssystem spezifisch sind. Tun Sie dies, indem Sie ein betriebssystemspezifisches Literal in die Datei tasks.json einfügen und die entsprechenden Eigenschaften in diesem Literal angeben.

Unten ist ein Beispiel, das die Node.js-ausführbare Datei 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 Betriebssystem-Eigenschaften sind windows für Windows, linux für Linux und osx für macOS. Eigenschaften, die in einem betriebssystemspezifischen Geltungsbereich definiert sind, überschreiben Eigenschaften, die im globalen oder Task-Geltungsbereich definiert sind.

Globale Tasks

Task-Eigenschaften können auch im globalen Geltungsbereich definiert werden. Wenn vorhanden, werden sie für bestimmte Tasks verwendet, es sei denn, sie definieren dieselbe Eigenschaft mit einem anderen Wert. Im folgenden Beispiel gibt es eine globale presentation-Eigenschaft, die definiert, dass alle Tasks in einem neuen Fenster 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 globale tasks.json-Datei zu erhalten, öffnen Sie die Befehlspalette (⇧⌘P (Windows, Linux Ctrl+Shift+P)) und führen Sie den Befehl Tasks: Benutzerdefinierte Tasks öffnen aus.

Zeichen-Escaping in PowerShell

Wenn die Standard-Shell PowerShell ist oder wenn ein Task für die Verwendung von PowerShell konfiguriert ist, können Sie unerwartete Leerzeichen- und Anführungszeichen-Escapings feststellen. Die unerwarteten Escapings treten nur bei Cmdlets auf, da VS Code nicht weiß, ob Ihr Befehl Cmdlets enthält. Beispiel 1 unten zeigt einen Fall, in dem Sie ein Escaping erhalten, das für PowerShell nicht funktioniert. Beispiel 2 zeigt den besten, plattformübergreifenden Weg, um ein gutes Escaping zu erzielen. In einigen Fällen können Sie Beispiel 2 nicht befolgen und müssen das manuelle Escaping durchführen, das in Beispiel 3 gezeigt wird.

"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 auf der Festplatte gespeichert sind, müssen Sie der als Task ausgeführten Befehlszeile mitteilen, welche Kodierung verwendet werden soll. Da dies vom Betriebssystem und der verwendeten Shell abhängt, gibt es keine allgemeine Lösung zur Steuerung. Nachfolgend finden Sie Ratschläge und Beispiele, wie dies funktionieren könnte.

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

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

{
  // 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 die Locale zu überprüfen und die erforderlichen Umgebungsvariablen anzupassen.

Beispiele für Tasks in Aktion

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

TypeScript nach JavaScript transpilieren

Das TypeScript-Thema enthält ein Beispiel, das einen Task zur Transpilierung von TypeScript nach JavaScript erstellt und verwandte Fehler innerhalb von VS Code beobachtet.

Less und SCSS nach CSS transpilieren

Das CSS-Thema bietet Beispiele, wie Tasks zum Generieren von CSS-Dateien verwendet werden können.

  1. Manuelle Transpilierung mit einem Build-Task
  2. Automatisierung des Kompilierungsschritts mit einem Dateibeobachter

Definieren eines Problem-Matchers

VS Code wird mit einigen der gängigsten Problem-Matcher "eingebaut" geliefert. Es gibt jedoch viele Compiler und Linting-Tools, die alle ihren eigenen Stil von Fehlern und Warnungen erzeugen, sodass Sie möglicherweise Ihren eigenen Problem-Matcher erstellen möchten.

Wir haben ein Programm helloWorld.c, in dem der Entwickler printf als prinft falsch geschrieben hat. Das Kompilieren 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 sind stark von Regulären Ausdrücken abhängig. Der folgende Abschnitt geht davon aus, dass Sie mit Regulären Ausdrücken vertraut sind.

Tipp: Wir haben das RegEx101-Spielplatz, das eine ECMAScript (JavaScript)-Variante hat, als großartige Möglichkeit zur Entwicklung und zum Testen von Regulären Ausdrücken gefunden.

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 zwingend erforderlich sind. fileLocation gibt an, ob die Dateipfade, die von der Task-Ausgabe erzeugt und im Problem abgeglichen werden, absolute oder relative sind. Wenn der Task sowohl absolute als auch relative Pfade erzeugt, können Sie autoDetect als Dateipfad verwenden. Mit autoDetect werden Pfade zuerst als absolute Pfade getestet, und wenn die Datei nicht existiert, wird angenommen, dass der Pfad relativ ist.

severity gibt an, welche Problem-Schwere 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 Datei tasks.json mit dem obigen Code (Kommentare entfernt), umschlossen 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
        }
      }
    }
  ]
}

Wenn Sie sie innerhalb von VS Code ausführen und ⇧⌘M (Windows, Linux Ctrl+Shift+M) drücken, um die Liste der Probleme zu erhalten, erhalten Sie die folgende Ausgabe

GCC Problem Matcher

Hinweis: Die C/C++-Erweiterung enthält Problem-Matcher für GCC, sodass wir keinen eigenen definieren müssen.

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

  • location - Wenn sich die Problemposition auf Zeile oder Zeile,Spalte oder StartZeile,StartSpalte,EndeZeile,EndeSpalte bezieht, kann unsere generische Positions-Match-Gruppe verwendet werden.
  • endLine - Der Index der Gruppe für die Endzeile des Problems. Kann weggelassen werden, wenn kein Endzeilenwert vom Compiler bereitgestellt wird.
  • endColumn - Der Index der Gruppe für die Endspalte des Problems. Kann weggelassen werden, wenn kein Endspaltenwert vom Compiler bereitgestellt wird.
  • code - Der Index der Gruppe für den Problemcode. Kann weggelassen werden, wenn kein Code-Wert vom Compiler bereitgestellt wird.

Sie können auch einen Problem-Matcher definieren, der nur eine Datei erfasst. Tun Sie dies, indem Sie ein pattern mit dem optionalen Attribut kind auf file setzen. In diesem Fall müssen Sie keine Eigenschaft line oder location angeben.

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

Hinweis: Der Problem-Matcher parst nur die Ausgabe des angegebenen Befehls. Wenn Sie die Ausgabe parsen möchten, die in einer separaten Datei geschrieben wird (z. B. einer Protokolldatei), lassen Sie den ausgeführten Befehl Zeilen aus der separaten Datei ausgeben, bevor er seine Ausführung beendet.

Definieren eines mehrzeiligen Problem-Matchers

Einige Tools verteilen Probleme, die in einer Quelldatei gefunden werden, über mehrere Zeilen, insbesondere wenn stilvolle Reporter verwendet werden. Ein Beispiel ist ESLint; im stilvollen 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 die tatsächliche Problemposition und -meldung (1:0 Fehler Fehlende "use strict"-Anweisung).

Um dies zu erreichen, verwenden Sie 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.

Das folgende Problem-Muster passt zur Ausgabe von ESLint im stilvollen Modus – hat aber immer noch ein kleines Problem, das wir als Nächstes lösen müssen. Der unten stehende Code hat einen ersten regulären Ausdruck zum Erfassen des Dateinamens und einen zweiten zum Erfassen von Zeile, Spalte, Schweregrad, Meldung und Fehlercode

{
  "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 mehr als ein Problem in einer Ressource auftritt. 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 stimmt mit "test.js" überein, der zweite mit "1:0 Fehler ...". Die nächste Zeile "1:9 Fehler ..." wird verarbeitet, stimmt aber nicht mit dem ersten regulären Ausdruck überein, sodass kein Problem erfasst wird.

Damit dies funktioniert, kann der letzte reguläre Ausdruck eines mehrzeiligen Musters die Eigenschaft loop angeben. Wenn diese 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 vom ersten Muster erfassten Informationen, das in diesem Fall test.js übereinstimmt, werden mit jeder der nachfolgenden Zeilen, die mit dem loop-Muster übereinstimmen, kombiniert, um mehrere Probleme zu erstellen. In diesem Beispiel würden sechs Probleme erstellt.

Hier ist ein Problem-Matcher, um ESLint-stilvolle 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 mehrere Probleme 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 vorhandenen Problem-Matchers

Wenn ein vorhandener Problem-Matcher dem nahe kommt, was Sie benötigen, können Sie ihn in Ihrer 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
}

Weitere modifizierbare Eigenschaften von Problem-Matchern sind background, fileLocation, owner, pattern, severity und source.

Hintergrund-/Watch-Tasks

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

Um Feedback zu geben, dass im VS Code eine Hintergrundaufgabe aktiv ist und Problemergebnisse erzeugt, muss ein Problem-Matcher zusätzliche Informationen verwenden, um diese state-Änderungen in der Ausgabe zu erkennen. Nehmen wir den tsc-Compiler als Beispiel. Wenn der Compiler im Watch-Modus gestartet wird, gibt er folgende zusätzliche Informationen auf der Konsole aus

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

Wenn sich eine Datei mit einem Problem auf der Festplatte ändert, 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.

Wenn man sich die Ausgabe ansieht, zeigt sich das folgende Muster

  • Der Compiler läuft, wenn File change detected. Starting incremental compilation... auf der Konsole ausgegeben wird.
  • Der Compiler stoppt, wenn Compilation complete. Watching for file changes. auf der Konsole ausgegeben wird.
  • Zwischen diesen beiden Zeichenketten werden Probleme gemeldet.
  • Der Compiler läuft auch einmalig beim initialen Start (ohne die Ausgabe von File change detected. Starting incremental compilation... auf der Konsole).

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

Für den tsc-Compiler sieht eine passende background-Eigenschaft wie folgt 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 die Aufgabe selbst als isBackground gekennzeichnet sein, damit die Aufgabe im Hintergrund weiterläuft.

Eine vollständige manuell erstellte tasks.json für eine tsc-Aufgabe im Watch-Modus sieht wie folgt 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 Aufgaben – machen wir weiter...

  • tasks.json Schema - Sie können das vollständige tasks.json-Schema und die Beschreibungen überprüfen.
  • 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 geliefert werden, als auch die über Community-Erweiterungen.
  • Debugging - Debuggen Sie Ihren Quellcode direkt im VS Code-Editor.

Häufig gestellte Fragen

Kann eine Aufgabe 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 die gesamte Automatisierung in VS Code verwendet wird, was auch Aufgaben einschließt.

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

Alternativ können Sie die Shell einer Aufgabe mit der options.shell-Eigenschaft überschreiben. Sie können dies pro Aufgabe, global oder pro Plattform festlegen. 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 eine Hintergrundaufgabe als prelaunchTask in launch.json verwendet werden?

Ja. Da eine Hintergrundaufgabe läuft, bis sie beendet wird, hat eine Hintergrundaufgabe für sich allein kein Signal, dass sie "abgeschlossen" ist. Um eine Hintergrundaufgabe als prelaunchTask zu verwenden, müssen Sie einen passenden Hintergrund problemMatcher zur Hintergrundaufgabe hinzufügen, damit das Aufgabensystem und das Debug-System wissen, dass die Aufgabe "beendet" ist.

Ihre Aufgabe könnte sein

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

Hinweis: Das $tsc-watch ist ein Hintergrund-Problem-Matcher, wie es für eine Hintergrundaufgabe erforderlich ist.

Sie können die Aufgabe 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 Hintergrundaufgaben finden Sie unter Hintergrund-/Watch-Aufgaben.

Warum erhalte ich die Meldung "command not found", wenn ich eine Aufgabe ausführe?

Die Meldung "command not found" tritt auf, wenn der von Ihnen ausgeführte Aufgabenbefehl von Ihrem Terminal nicht als ausführbar erkannt wird. Am häufigsten geschieht dies, weil der Befehl als Teil der Startskripte Ihrer Shell konfiguriert ist. Aufgaben werden nicht als Login und nicht interaktiv ausgeführt, was bedeutet, dass die Startskripte Ihrer Shell nicht ausgeführt werden. nvm ist dafür bekannt, Startskripte als Teil seiner Konfiguration zu verwenden.

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

  1. Stellen Sie sicher, dass Ihr Befehl in Ihrem Pfad liegt und keine Startskripte benötigt, um zu 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 vornehmen, damit Ihre Aufgabe als Login oder interaktiv ausgeführt wird. Dies wird nicht empfohlen, da es andere Konsequenzen haben kann. Es kann jedoch auch eine schnelle und einfache Lösung für eine einzelne Aufgabe sein. Unten sehen Sie ein Beispiel für eine Aufgabe, die dies mit bash als Shell tut
{
  "type": "npm",
  "script": "watch",
  "options": {
    "shell": {
      "args": ["-c", "-l"]
    }
  }
}

Die obige npm-Aufgabe führt bash mit einem Befehl (-c) aus, genau wie das Aufgabensystem standardmäßig. Diese Aufgabe führt jedoch bash auch als Login-Shell (-l) aus.

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