Unterstützung für Remote-Entwicklung und GitHub Codespaces

Visual Studio Code Remote Development ermöglicht Ihnen die transparente Interaktion mit Quellcode und Laufzeitumgebungen auf anderen Rechnern (egal ob virtuell oder physisch). GitHub Codespaces ist ein Dienst, der diese Fähigkeiten mit verwalteten Cloud-gehosteten Umgebungen erweitert, auf die sowohl von VS Code als auch von einem browserbasierten Editor zugegriffen werden kann.

Um die Leistung zu gewährleisten, führen Remote Development und GitHub Codespaces bestimmte VS Code-Erweiterungen transparent remote aus. Dies kann jedoch subtile Auswirkungen darauf haben, wie Erweiterungen funktionieren müssen. Während viele Erweiterungen ohne Änderungen funktionieren, müssen Sie möglicherweise Änderungen vornehmen, damit Ihre Erweiterung in allen Umgebungen ordnungsgemäß funktioniert, obwohl diese Änderungen oft recht geringfügig sind.

Dieser Artikel fasst zusammen, was Erweiterungsautoren über Remote Development und Codespaces wissen müssen, einschließlich der Erweiterungs-Architektur, wie Sie Ihre Erweiterung debuggen in Remote-Workspaces oder Codespaces und Empfehlungen, was zu tun ist, wenn Ihre Erweiterung nicht ordnungsgemäß funktioniert.

Architektur und Erweiterungsarten

Um die Arbeit mit Remote Development oder Codespaces für Benutzer so transparent wie möglich zu gestalten, unterscheidet VS Code zwei Arten von Erweiterungen

• UI-Erweiterungen: Diese Erweiterungen tragen zur Benutzeroberfläche von VS Code bei und werden immer auf dem lokalen Rechner des Benutzers ausgeführt. UI-Erweiterungen können nicht direkt auf Dateien im Remote-Workspace zugreifen oder Skripte/Tools ausführen, die in diesem Workspace oder auf dem Rechner installiert sind. Beispiele für UI-Erweiterungen sind: Themes, Snippets, Grammatiken für Sprachen und Tastenkombinationen.

• Workspace-Erweiterungen: Diese Erweiterungen werden auf demselben Rechner ausgeführt, auf dem sich der Workspace befindet. Wenn Sie sich in einem lokalen Workspace befinden, werden Workspace-Erweiterungen auf dem lokalen Rechner ausgeführt. Wenn Sie sich in einem Remote-Workspace befinden oder Codespaces verwenden, werden Workspace-Erweiterungen auf dem Remote-Rechner/der Remote-Umgebung ausgeführt. Workspace-Erweiterungen können auf Dateien im Workspace zugreifen, um reichhaltige, mehrdateilige Sprachdienste, Debugger-Unterstützung bereitzustellen oder komplexe Operationen auf mehreren Dateien im Workspace durchzuführen (entweder direkt oder durch Aufrufen von Skripten/Tools). Obwohl sich Workspace-Erweiterungen nicht auf die Änderung der Benutzeroberfläche konzentrieren, können sie auch Explorer, Ansichten und andere UI-Elemente beitragen.

Wenn ein Benutzer eine Erweiterung installiert, installiert VS Code sie automatisch am richtigen Speicherort basierend auf ihrer Art. Wenn eine Erweiterung als eine der beiden Arten ausgeführt werden kann, versucht VS Code, die optimale für die Situation auszuwählen. UI-Erweiterungen werden im lokalen Extension Host von VS Code ausgeführt, während Workspace-Erweiterungen in einem Remote Extension Host ausgeführt werden, der sich in einem kleinen VS Code Server befindet, falls dieser in einem Remote-Workspace vorhanden ist, andernfalls wird er im lokalen Extension Host von VS Code ausgeführt, falls er lokal vorhanden ist. Um sicherzustellen, dass die neuesten VS Code-Clientfunktionen verfügbar sind, muss der Server exakt mit der VS Code-Clientversion übereinstimmen. Daher wird der Server automatisch von den Remote Development- oder GitHub Codespaces-Erweiterungen installiert (oder aktualisiert), wenn Sie einen Ordner in einem Container, auf einem entfernten SSH-Host, mit Codespaces oder im Windows Subsystem für Linux (WSL) öffnen. (VS Code verwaltet auch das Starten und Stoppen des Servers automatisch, sodass Benutzer von seiner Existenz nichts bemerken.)

Die VS Code-APIs sind so konzipiert, dass sie beim Aufruf von UI- oder Workspace-Erweiterungen automatisch auf dem richtigen Rechner (entweder lokal oder remote) ausgeführt werden. Wenn Ihre Erweiterung jedoch APIs verwendet, die nicht von VS Code bereitgestellt werden, wie z. B. Node-APIs oder die Ausführung von Shell-Skripten, funktioniert sie möglicherweise nicht ordnungsgemäß, wenn sie remote ausgeführt wird. Wir empfehlen Ihnen, zu testen, ob alle Funktionen Ihrer Erweiterung sowohl in lokalen als auch in Remote-Workspaces ordnungsgemäß funktionieren.

Erweiterungen debuggen

Während Sie eine Entwicklungsversion Ihrer Erweiterung installieren können, um sie in einer Remote-Umgebung zu testen, möchten Sie Ihre Erweiterung wahrscheinlich direkt in einer Remote-Umgebung debuggen, wenn Probleme auftreten. In diesem Abschnitt behandeln wir, wie Sie Ihre Erweiterung in GitHub Codespaces, einem lokalen Container, einem SSH-Host oder in WSL bearbeiten, starten und debuggen.

Normalerweise ist der beste Ausgangspunkt für Tests eine Remote-Umgebung, die den Portzugriff einschränkt (z. B. Codespaces, ein Container oder Remote-SSH-Hosts mit einer restriktiven Firewall), da Erweiterungen, die in diesen Umgebungen funktionieren, tendenziell auch in weniger restriktiven Umgebungen wie WSL funktionieren.

Debugging mit GitHub Codespaces

Das Debugging Ihrer Erweiterung in der Vorschau von GitHub Codespaces kann ein großartiger Ausgangspunkt sein, da Sie sowohl VS Code als auch den browserbasierten Editor von Codespaces zum Testen und zur Fehlerbehebung verwenden können. Sie können bei Bedarf auch einen benutzerdefinierten Entwicklungcontainer verwenden.

Befolgen Sie diese Schritte:

1. Navigieren Sie zum Repository, das Ihre Erweiterung auf GitHub enthält, und öffnen Sie es in einem Codespace, um damit in einem browserbasierten Editor zu arbeiten. Sie können den Codespace auch in VS Code öffnen, wenn Sie dies bevorzugen.

2. Während das Standard-Image für GitHub Codespaces alle erforderlichen Voraussetzungen für die meisten Erweiterungen enthalten sollte, können Sie alle weiteren erforderlichen Abhängigkeiten (z. B. mit yarn install oder sudo apt-get) in einem neuen VS Code-Terminalfenster installieren (⌃⇧` (Windows, Linux Ctrl+Shift+`)).

3. Drücken Sie schließlich F5 oder verwenden Sie die Ansicht Ausführen und Debuggen, um die Erweiterung innerhalb des Codespace zu starten.

   Hinweis: Sie können den Quellcodeordner der Erweiterung nicht im erscheinenden Fenster öffnen, aber Sie können einen Unterordner oder etwas anderes im Codespace öffnen.

Das erscheinende Fenster des Erweiterungsentwicklungs-Hosts enthält Ihre Erweiterung, die in einem Codespace mit angehängtem Debugger ausgeführt wird.

Debugging in einem benutzerdefinierten Entwicklungcontainer

Befolgen Sie diese Schritte:

1. Um einen Entwicklungcontainer lokal zu verwenden, installieren und konfigurieren Sie die Dev Containers-Erweiterung und verwenden Sie Datei > Öffnen... / Ordner öffnen..., um Ihren Quellcode lokal in VS Code zu öffnen. Um stattdessen Codespaces zu verwenden, navigieren Sie zum Repository, das Ihre Erweiterung auf GitHub enthält, und öffnen Sie es in einem Codespace, um damit in einem browserbasierten Editor zu arbeiten. Sie können den Codespace auch in VS Code öffnen, wenn Sie dies bevorzugen.

2. Wählen Sie im Befehlspaletten (F1) Dev Containers: Dev Container-Konfigurationsdateien hinzufügen... oder Codespaces: Dev Container-Konfigurationsdateien hinzufügen... und wählen Sie Node.js & TypeScript (oder Node.js, wenn Sie kein TypeScript verwenden), um die erforderlichen Container-Konfigurationsdateien hinzuzufügen.

3. Optional: Nach Ausführung dieses Befehls können Sie den Inhalt des .devcontainer-Ordners ändern, um zusätzliche Build- oder Laufzeitanforderungen hinzuzufügen. Weitere Informationen finden Sie in der ausführlichen Dokumentation Erstellen eines Dev Containers.

4. Führen Sie Dev Containers: Erneut im Container öffnen oder Codespaces: Dev Container-Konfigurationsdateien hinzufügen... aus, und in einem Moment wird VS Code den Container einrichten und eine Verbindung herstellen. Sie können dann Ihren Quellcode aus dem Container heraus entwickeln, genau wie im lokalen Fall.

5. Führen Sie yarn install oder npm install in einem neuen VS Code-Terminalfenster (⌃⇧` (Windows, Linux Ctrl+Shift+`)) aus, um sicherzustellen, dass die nativen Node.js-Abhängigkeiten für Linux-Versionen installiert sind. Sie können auch andere Betriebssystem- oder Laufzeitabhängigkeiten installieren, aber Sie möchten diese möglicherweise auch zu .devcontainer/Dockerfile hinzufügen, damit sie verfügbar sind, wenn Sie den Container neu erstellen.

6. Drücken Sie schließlich F5 oder verwenden Sie die Ansicht Ausführen und Debuggen, um die Erweiterung in demselben Container zu starten und den Debugger anzuhängen.

   Hinweis: Sie können den Quellcodeordner der Erweiterung nicht im erscheinenden Fenster öffnen, aber Sie können einen Unterordner oder etwas anderes im Container öffnen.

Das erscheinende Fenster des Erweiterungsentwicklungs-Hosts enthält Ihre Erweiterung, die in dem in Schritt 2 definierten Container mit angehängtem Debugger ausgeführt wird.

Debugging über SSH

Folgen Sie den Schritten

1. Nachdem Sie die Remote - SSH-Erweiterung installiert und konfiguriert haben, wählen Sie im Befehlspaletten (F1) in VS Code Remote-SSH: Verbindung zu Host herstellen..., um eine Verbindung zu einem Host herzustellen.

2. Sobald Sie verbunden sind, verwenden Sie entweder Datei > Öffnen... / Ordner öffnen..., um den Remote-Ordner mit dem Quellcode Ihrer Erweiterung auszuwählen, oder wählen Sie Git: Klonen aus dem Befehlspaletten (F1), um ihn zu klonen und auf dem Remote-Host zu öffnen.

3. Installieren Sie alle erforderlichen Abhängigkeiten, die möglicherweise fehlen (z. B. mit yarn install oder apt-get), in einem neuen VS Code-Terminalfenster (⌃⇧` (Windows, Linux Ctrl+Shift+`)).

4. Drücken Sie schließlich F5 oder verwenden Sie die Ansicht Ausführen und Debuggen, um die Erweiterung auf dem Remote-Host zu starten und den Debugger anzuhängen.

   Hinweis: Sie können den Quellcodeordner der Erweiterung im erscheinenden Fenster nicht öffnen, aber Sie können einen Unterordner oder etwas anderes auf dem SSH-Host öffnen.

Das erscheinende Fenster des Erweiterungsentwicklungs-Hosts enthält Ihre Erweiterung, die auf dem SSH-Host mit angehängtem Debugger ausgeführt wird.

Debugging mit WSL

Befolgen Sie diese Schritte:

1. Nachdem Sie die WSL-Erweiterung installiert und konfiguriert haben, wählen Sie im Befehlspaletten (F1) in VS Code WSL: Neues Fenster.

2. In dem neuen erscheinenden Fenster verwenden Sie entweder Datei > Öffnen... / Ordner öffnen..., um den Remote-Ordner mit dem Quellcode Ihrer Erweiterung auszuwählen, oder wählen Sie Git: Klonen aus dem Befehlspaletten (F1), um ihn zu klonen und in WSL zu öffnen.

   Tipp: Sie können den Ordner /mnt/c auswählen, um auf jeden geklonten Quellcode zuzugreifen, den Sie auf der Windows-Seite haben.

3. Installieren Sie alle erforderlichen Abhängigkeiten, die möglicherweise fehlen (z. B. mit apt-get), in einem neuen VS Code-Terminalfenster (⌃⇧` (Windows, Linux Ctrl+Shift+`)). Sie werden mindestens yarn install oder npm install ausführen wollen, um sicherzustellen, dass native Node.js-Abhängigkeiten für Linux-Versionen verfügbar sind.

4. Drücken Sie schließlich F5 oder verwenden Sie die Ansicht Ausführen und Debuggen, um die Erweiterung zu starten und den Debugger anzuhängen, genau wie Sie es lokal tun würden.

   Hinweis: Sie können den Quellcodeordner der Erweiterung im erscheinenden Fenster nicht öffnen, aber Sie können einen Unterordner oder etwas anderes in WSL öffnen.

Das erscheinende Fenster des Erweiterungsentwicklungs-Hosts enthält Ihre Erweiterung, die in WSL mit angehängtem Debugger ausgeführt wird.

Installation einer Entwicklungsversion Ihrer Erweiterung

Jedes Mal, wenn VS Code eine Erweiterung automatisch auf einem SSH-Host, in einem Container oder WSL oder über GitHub Codespaces installiert, wird die Marketplace-Version verwendet (und nicht die Version, die bereits auf Ihrem lokalen Rechner installiert ist).

Während dies in den meisten Fällen sinnvoll ist, möchten Sie möglicherweise eine unveröffentlichte Version Ihrer Erweiterung zum Testen verwenden (oder teilen), ohne eine Debugging-Umgebung einrichten zu müssen. Um eine unveröffentlichte Version Ihrer Erweiterung zu installieren, können Sie die Erweiterung als VSIX paketieren und manuell in ein VS Code-Fenster installieren, das bereits mit einer laufenden Remote-Umgebung verbunden ist.

Befolgen Sie diese Schritte:

1. Wenn es sich um eine veröffentlichte Erweiterung handelt, möchten Sie möglicherweise "extensions.autoUpdate": false zu settings.json hinzufügen, um zu verhindern, dass sie automatisch auf die neueste Marketplace-Version aktualisiert wird.
2. Verwenden Sie dann vsce package, um Ihre Erweiterung als VSIX zu paketieren.
3. Verbinden Sie sich mit einem Codespace, Dev Containers, SSH-Host oder einer WSL-Umgebung.
4. Verwenden Sie den Befehl Von VSIX installieren..., der im Menü Weitere Aktionen (...) der Erweiterungsansicht verfügbar ist, um die Erweiterung in diesem spezifischen Fenster zu installieren (nicht in einem lokalen).
5. Laden Sie neu, wenn Sie dazu aufgefordert werden.

Tipp: Nach der Installation können Sie den Befehl Entwickler: Laufende Erweiterungen anzeigen verwenden, um zu sehen, ob VS Code die Erweiterung lokal oder remote ausführt.

Abhängigkeiten mit Remote-Erweiterungen verwalten

Erweiterungen können Abhängigkeiten von anderen Erweiterungen für APIs haben. Zum Beispiel

• Eine Erweiterung kann eine API aus ihrer activate-Funktion exportieren.
• Diese API wird für alle Erweiterungen verfügbar, die im selben Erweiterungs-Host ausgeführt werden.
• Konsumentenerweiterungen deklarieren in ihrer package.json, dass sie von der bereitstellenden Erweiterung abhängen, indem sie die Eigenschaft extensionDependencies verwenden.

Erweiterungsabhängigkeiten funktionieren gut, wenn alle Erweiterungen lokal ausgeführt werden und denselben Erweiterungs-Host teilen.

Wenn Sie mit Remote-Szenarien umgehen, ist es möglich, dass eine remote ausgeführte Erweiterung eine Erweiterungsabhängigkeit von einer lokal ausgeführten Erweiterung hat. Zum Beispiel stellt die lokale Erweiterung einen Befehl bereit, der für die Funktionsweise der Remote-Erweiterung entscheidend ist. In diesem Fall empfehlen wir, dass die Remote-Erweiterung die lokale Erweiterung als extensionDependency deklariert. Das Problem ist jedoch, dass die Erweiterungen auf zwei verschiedenen Erweiterungs-Hosts ausgeführt werden, was bedeutet, dass die API des Anbieters für den Konsumenten nicht verfügbar ist. Daher ist es erforderlich, dass die bereitstellende Erweiterung vollständig auf die Fähigkeit verzichtet, APIs zu exportieren, indem sie "api": "none" in der package.json ihrer Erweiterung verwendet. Die Erweiterungen können immer noch über VS Code-Befehle (die asynchron sind) kommunizieren.

Dies mag wie eine unnötig strenge Einschränkung für die bereitstellende Erweiterung erscheinen, aber eine Erweiterung, die "api": "none" verwendet, verzichtet nur auf die Fähigkeit, APIs aus ihrer activate-Methode zurückzugeben. Konsumentenerweiterungen, die auf anderen Erweiterungs-Hosts ausgeführt werden, können weiterhin von ihnen abhängen und werden aktiviert.

Häufige Probleme

Die VS Code-APIs sind so konzipiert, dass sie an der richtigen Stelle ausgeführt werden, unabhängig davon, wo sich Ihre Erweiterung befindet. Vor diesem Hintergrund gibt es einige APIs, die Ihnen helfen, unerwartetes Verhalten zu vermeiden.

Falscher Ausführungsort

Wenn Ihre Erweiterung nicht wie erwartet funktioniert, wird sie möglicherweise am falschen Ort ausgeführt. Am häufigsten tritt dies auf, wenn eine Erweiterung remote ausgeführt wird, obwohl Sie erwarten, dass sie nur lokal ausgeführt wird. Sie können den Befehl Entwickler: Laufende Erweiterungen anzeigen aus dem Befehlspaletten (F1) verwenden, um zu sehen, wo eine Erweiterung ausgeführt wird.

Wenn der Befehl Entwickler: Laufende Erweiterungen anzeigen zeigt, dass eine UI-Erweiterung fälschlicherweise als Workspace-Erweiterung behandelt wird oder umgekehrt, versuchen Sie, die Eigenschaft extensionKind in der package.json Ihrer Erweiterung festzulegen, wie im Abschnitt Extension Kinds beschrieben.

Sie können die Auswirkung der Änderung des Typs einer Erweiterung schnell mit der Einstellung remote.extensionKind testen. Diese Einstellung ist eine Zuordnung von Erweiterungs-IDs zu Erweiterungs-Arten. Wenn Sie beispielsweise die Erweiterung Azure Databases zwingen möchten, eine UI-Erweiterung zu sein (anstelle ihres standardmäßigen Workspace-Typs) und die Erweiterung Remote - SSH: Konfigurationsdateien bearbeiten zu einer Workspace-Erweiterung (anstelle ihres standardmäßigen UI-Typs), würden Sie Folgendes festlegen

{
  "remote.extensionKind": {
    "ms-azuretools.vscode-cosmosdb": ["ui"],
    "ms-vscode-remote.remote-ssh-edit": ["workspace"]
  }
}

Die Verwendung von remote.extensionKind ermöglicht es Ihnen, veröffentlichte Versionen von Erweiterungen schnell zu testen, ohne deren package.json ändern und neu kompilieren zu müssen.

Persistente Erweiterungsdaten oder -status

In einigen Fällen muss Ihre Erweiterung Statusinformationen speichern, die nicht in settings.json oder einer separaten Workspace-Konfigurationsdatei (z. B. .eslintrc) gehören. Um dieses Problem zu lösen, stellt VS Code eine Reihe hilfreicher Speichereigenschaften im vscode.ExtensionContext-Objekt bereit, das Ihrer Erweiterung während der Aktivierung übergeben wird. Wenn Ihre Erweiterung diese Eigenschaften bereits nutzt, sollte sie unabhängig davon, wo sie ausgeführt wird, weiterhin funktionieren.

Wenn Ihre Erweiterung jedoch von aktuellen VS Code-Pfadkonventionen (z. B. ~/.vscode) oder der Anwesenheit bestimmter OS-Ordner (z. B. ~/.config/Code unter Linux) zum Speichern von Daten abhängt, können Probleme auftreten. Glücklicherweise sollte es einfach sein, Ihre Erweiterung zu aktualisieren und diese Herausforderungen zu vermeiden.

Wenn Sie einfache Schlüssel-Wert-Paare speichern, können Sie Workspace-spezifische oder globale Statusinformationen mit vscode.ExtensionContext.workspaceState oder vscode.ExtensionContext.globalState speichern. Wenn Ihre Daten komplexer als Schlüssel-Wert-Paare sind, bieten die Eigenschaften globalStorageUri und storageUri "sichere" URIs, die Sie zum Lesen/Schreiben globaler Workspace-spezifischer Informationen in einer Datei verwenden können.

So verwenden Sie die APIs

import * as vscode from 'vscode';

export function activate(context: vscode.ExtensionContext) {
    context.subscriptions.push(
        vscode.commands.registerCommand('myAmazingExtension.persistWorkspaceData', async () => {
            if (!context.storageUri) {
                return;
            }

            // Create the extension's workspace storage folder if it doesn't already exist
            try {
                // When folder doesn't exist, and error gets thrown
                await vscode.workspace.fs.stat(context.storageUri);
            } catch {
                // Create the extension's workspace storage folder
                await vscode.workspace.fs.createDirectory(context.storageUri)
            }

            const workspaceData = vscode.Uri.joinPath(context.storageUri, 'workspace-data.json');
            const writeData = new TextEncoder().encode(JSON.stringify({ now: Date.now() }));
            vscode.workspace.fs.writeFile(workspaceData, writeData);
        }
    ));

    context.subscriptions.push(
        vscode.commands.registerCommand('myAmazingExtension.persistGlobalData', async () => {

        if (!context.globalStorageUri) {
            return;
        }

        // Create the extension's global (cross-workspace) folder if it doesn't already exist
        try {
            // When folder doesn't exist, and error gets thrown
            await vscode.workspace.fs.stat(context.globalStorageUri);
        } catch {
            await vscode.workspace.fs.createDirectory(context.globalStorageUri)
        }

        const workspaceData = vscode.Uri.joinPath(context.globalStorageUri, 'global-data.json');
        const writeData = new TextEncoder().encode(JSON.stringify({ now: Date.now() }));
        vscode.workspace.fs.writeFile(workspaceData, writeData);
    ));
}

Synchronisieren des globalen Benutzerzustands zwischen Rechnern

Wenn Ihre Erweiterung benutzerdefinierte Zustände über verschiedene Rechner hinweg erhalten muss, stellen Sie den Zustand für Einstellungen-Synchronisierung über vscode.ExtensionContext.globalState.setKeysForSync bereit. Dies kann dazu beitragen, zu verhindern, dass Benutzern auf mehreren Rechnern dieselbe Willkommens- oder Update-Seite angezeigt wird.

Es gibt ein Beispiel für die Verwendung von setKeysforSync im Thema Erweiterungsfunktionen.

Speichern von Geheimnissen

Wenn Ihre Erweiterung Passwörter oder andere Geheimnisse speichern muss, möchten Sie möglicherweise die SecretStorage API von Visual Studio Code verwenden, die eine Möglichkeit bietet, Text sicher auf dem Dateisystem zu speichern, unterstützt durch Verschlüsselung. Zum Beispiel verwenden wir auf dem Desktop die safeStorage API von Electron, um Geheimnisse vor dem Speichern auf dem Dateisystem zu verschlüsseln. Die API speichert die Geheimnisse immer auf der Client-Seite, aber Sie können diese API unabhängig davon verwenden, wo Ihre Erweiterung ausgeführt wird, und dieselben Geheimniswerte abrufen.

Hinweis: Diese API ist die empfohlene Methode zum Speichern von Passwörtern und Geheimnissen. Sie sollten Ihre Geheimnisse nicht mit vscode.ExtensionContext.workspaceState oder vscode.ExtensionContext.globalState speichern, da diese APIs Daten im Klartext speichern.

Hier ist ein Beispiel

import * as vscode from 'vscode';

export function activate(context: vscode.ExtensionContext) {
  // ...
  const myApiKey = context.secrets.get('apiKey');
  // ...
  context.secrets.delete('apiKey');
  // ...
  context.secrets.store('apiKey', myApiKey);
}

Verwendung der Zwischenablage

Historisch gesehen haben Erweiterungsautoren Node.js-Module wie clipboardy verwendet, um mit der Zwischenablage zu interagieren. Wenn Sie diese Module in einer Workspace-Erweiterung verwenden, greifen sie leider auf die Remote-Zwischenablage anstelle der lokalen des Benutzers zu. Die VS Code-Zwischenablagen-API löst dieses Problem. Sie wird immer lokal ausgeführt, unabhängig von der Art der aufrufenden Erweiterung.

So verwenden Sie die VS Code-Zwischenablagen-API in einer Erweiterung

import * as vscode from 'vscode';

export function activate(context: vscode.ExtensionContext) {
  context.subscriptions.push(
    vscode.commands.registerCommand('myAmazingExtension.clipboardIt', async () => {
      // Read from clipboard
      const text = await vscode.env.clipboard.readText();

      // Write to clipboard
      await vscode.env.clipboard.writeText(
        `It looks like you're copying "${text}". Would you like help?`
      );
    })
  );
}

Öffnen von etwas in einem lokalen Browser oder einer Anwendung

Das Erzeugen eines Prozesses oder die Verwendung eines Moduls wie opn zum Starten eines Browsers oder einer anderen Anwendung für eine bestimmte URI kann für lokale Szenarien gut funktionieren, aber Workspace-Erweiterungen werden remote ausgeführt, was dazu führen kann, dass die Anwendung auf der falschen Seite gestartet wird. VS Code Remote Development schimpt das opn-Knotenmodul teilweise, um bestehenden Erweiterungen die Funktionalität zu ermöglichen. Sie können das Modul mit einer URI aufrufen und VS Code wird die Standardanwendung für die URI auf der Client-Seite anzeigen lassen. Dies ist jedoch keine vollständige Implementierung, da Optionen nicht unterstützt werden und kein child_process-Objekt zurückgegeben wird.

Anstatt sich auf ein Drittanbieter-Knotenmodul zu verlassen, empfehlen wir, dass Erweiterungen die Methode vscode.env.openExternal nutzen, um die auf Ihrem lokalen Betriebssystem registrierte Standardanwendung für eine gegebene URI zu starten. Noch besser: vscode.env.openExternal leitet automatisch localhost-Ports weiter! Sie können sie verwenden, um auf einen lokalen Webserver auf einem Remote-Rechner oder Codespace zu verweisen und Inhalte bereitzustellen, selbst wenn dieser Port extern blockiert ist.

Hinweis: Derzeit unterstützt der Weiterleitungsmechanismus im browserbasierten Editor von Codespaces nur HTTP- und HTTPS-Anfragen. Sie können jedoch mit jeder TCP-Verbindung interagieren, wenn Sie sich mit einem Codespace von VS Code aus verbinden.

So verwenden Sie die vscode.env.openExternal-API

import * as vscode from 'vscode';

export async function activate(context: vscode.ExtensionContext) {
  context.subscriptions.push(
    vscode.commands.registerCommand('myAmazingExtension.openExternal', () => {
      // Example 1 - Open the VS Code homepage in the default browser.
      vscode.env.openExternal(vscode.Uri.parse('https://visualstudiocode.de'));

      // Example 2 - Open an auto-forwarded localhost HTTP server.
      vscode.env.openExternal(vscode.Uri.parse('https://:3000'));

      // Example 3 - Open the default email application.
      vscode.env.openExternal(vscode.Uri.parse('mailto:<fill in your email here>'));
    })
  );
}

Weiterleitung von localhost

Während der Weiterleitungsmechanismus für localhost in vscode.env.openExternal nützlich ist, kann es auch Situationen geben, in denen Sie etwas weiterleiten möchten, ohne tatsächlich ein neues Browserfenster oder eine Anwendung zu starten. Hier kommt die API vscode.env.asExternalUri ins Spiel.

Hinweis: Derzeit unterstützt der Weiterleitungsmechanismus im browserbasierten Editor von Codespaces nur HTTP- und HTTPS-Anfragen. Sie können jedoch mit jeder TCP-Verbindung interagieren, wenn Sie sich mit einem Codespace von VS Code aus verbinden.

So verwenden Sie die vscode.env.asExternalUri-API

import * as vscode from 'vscode';
import { getExpressServerPort } from './server';

export async function activate(context: vscode.ExtensionContext) {

    const dynamicServerPort = await getWebServerPort();

    context.subscriptions.push(vscode.commands.registerCommand('myAmazingExtension.forwardLocalhost', async () =>

        // Make the port available locally and get the full URI
        const fullUri = await vscode.env.asExternalUri(
            vscode.Uri.parse(`https://:${dynamicServerPort}`));

        // ... do something with the fullUri ...

    }));
}

Es ist wichtig zu beachten, dass die von der API zurückgegebene URI möglicherweise gar nicht auf localhost verweist, daher sollten Sie sie vollständig verwenden. Dies ist besonders wichtig für den browserbasierten Editor von Codespaces, wo localhost nicht verwendet werden kann.

Callbacks und URI-Handler

Die API vscode.window.registerUriHandler ermöglicht es Ihrer Erweiterung, eine benutzerdefinierte URI zu registrieren, die beim Öffnen in einem Browser eine Callback-Funktion in Ihrer Erweiterung auslöst. Ein häufiger Anwendungsfall für die Registrierung eines URI-Handlers ist die Implementierung einer Dienst-Anmeldung bei einem OAuth 2.0-Authentifizierungsanbieter (z. B. Azure AD). Sie kann jedoch für jedes Szenario verwendet werden, in dem Sie möchten, dass eine externe Anwendung oder der Browser Informationen an Ihre Erweiterung sendet.

Die Erweiterungen für Remote Development und Codespaces in VS Code leiten die URI transparent an Ihre Erweiterung weiter, unabhängig davon, wo sie tatsächlich ausgeführt wird (lokal oder remote). vscode://-URIs funktionieren jedoch nicht mit dem browserbasierten Editor von Codespaces, da das Öffnen dieser URIs in etwas wie einem Browser versuchen würde, sie an den lokalen VS Code-Client und nicht an den browserbasierten Editor zu übergeben. Glücklicherweise kann dies leicht durch die Verwendung der API vscode.env.asExternalUri behoben werden.

Verwenden wir eine Kombination aus vscode.window.registerUriHandler und vscode.env.asExternalUri, um einen Beispiel-OAuth-Authentifizierungs-Callback einzurichten

import * as vscode from 'vscode';

// This is ${publisher}.${name} from package.json
const extensionId = 'my.amazing-extension';

export async function activate(context: vscode.ExtensionContext) {
  // Register a URI handler for the authentication callback
  vscode.window.registerUriHandler({
    handleUri(uri: vscode.Uri): vscode.ProviderResult<void> {
      // Add your code for what to do when the authentication completes here.
      if (uri.path === '/auth-complete') {
        vscode.window.showInformationMessage('Sign in successful!');
      }
    }
  });

  // Register a sign in command
  context.subscriptions.push(
    vscode.commands.registerCommand(`${extensionId}.signin`, async () => {
      // Get an externally addressable callback URI for the handler that the authentication provider can use
      const callbackUri = await vscode.env.asExternalUri(
        vscode.Uri.parse(`${vscode.env.uriScheme}://${extensionId}/auth-complete`)
      );

      // Add your code to integrate with an authentication provider here - we'll fake it.
      vscode.env.clipboard.writeText(callbackUri.toString());
      await vscode.window.showInformationMessage(
        'Open the URI copied to the clipboard in a browser window to authorize.'
      );
    })
  );
}

Beim Ausführen dieses Beispiels in VS Code wird eine vscode://- oder vscode-insiders://-URI eingerichtet, die als Callback für einen Authentifizierungsanbieter verwendet werden kann. Beim Ausführen im browserbasierten Editor von Codespaces wird eine https://*.github.dev-URI ohne Codeänderungen oder spezielle Bedingungen eingerichtet.

Obwohl OAuth außerhalb des Rahmens dieses Dokuments liegt, beachten Sie, dass Sie, wenn Sie dieses Beispiel für einen echten Authentifizierungsanbieter anpassen, möglicherweise einen Proxy-Dienst vor den Anbieter schalten müssen. Dies liegt daran, dass nicht alle Anbieter vscode://-Callback-URIs zulassen und andere keine Wildcard-Hostnamen für Callbacks über HTTPS zulassen. Wir empfehlen außerdem, wann immer möglich einen OAuth 2.0 Authorization Code mit PKCE-Flow zu verwenden (z. B. unterstützt Azure AD PKCE), um die Sicherheit des Callbacks zu verbessern.

Unterschiedliche Verhaltensweisen bei Ausführung im Remote-Modus oder im browserbasierten Codespaces-Editor

In einigen Fällen muss Ihre Workspace-Erweiterung das Verhalten bei der Remote-Ausführung ändern. In anderen Fällen möchten Sie ihr Verhalten ändern, wenn sie im browserbasierten Editor von Codespaces ausgeführt wird. VS Code stellt drei APIs bereit, um diese Situationen zu erkennen: vscode.env.uiKind, extension.extensionKind und vscode.env.remoteName.

Als Nächstes können Sie die drei APIs wie folgt verwenden

import * as vscode from 'vscode';

export async function activate(context: vscode.ExtensionContext) {
  // extensionKind returns ExtensionKind.UI when running locally, so use this to detect remote
  const extension = vscode.extensions.getExtension('your.extensionId');
  if (extension.extensionKind === vscode.ExtensionKind.Workspace) {
    vscode.window.showInformationMessage('I am running remotely!');
  }

  // Codespaces browser-based editor will return UIKind.Web for uiKind
  if (vscode.env.uiKind === vscode.UIKind.Web) {
    vscode.window.showInformationMessage('I am running in the Codespaces browser editor!');
  }

  // VS Code will return undefined for remoteName if working with a local workspace
  if (typeof vscode.env.remoteName === 'undefined') {
    vscode.window.showInformationMessage('Not currently connected to a remote workspace.');
  }
}

Kommunikation zwischen Erweiterungen über Befehle

Einige Erweiterungen geben APIs als Teil ihrer Aktivierung zurück, die für die Verwendung durch andere Erweiterungen bestimmt sind (über vscode.extension.getExtension(extensionName).exports). Während diese funktionieren, wenn alle beteiligten Erweiterungen auf derselben Seite laufen (entweder alle UI-Erweiterungen oder alle Workspace-Erweiterungen), funktionieren sie nicht zwischen UI- und Workspace-Erweiterungen.

Glücklicherweise leitet VS Code automatisch alle ausgeführten Befehle an die richtige Erweiterung weiter, unabhängig von deren Speicherort. Sie können beliebige Befehle (einschließlich der von anderen Erweiterungen bereitgestellten) aufrufen, ohne sich Gedanken über Auswirkungen machen zu müssen.

Wenn Sie eine Reihe von Erweiterungen haben, die miteinander interagieren müssen, kann das Offenlegen von Funktionalität über einen privaten Befehl Ihnen helfen, unerwartete Auswirkungen zu vermeiden. Alle als Parameter übergebenen Objekte werden jedoch vor der Übertragung "serialisiert" (JSON.stringify), sodass das Objekt keine zyklischen Referenzen haben kann und auf der anderen Seite als "einfaches JavaScript-Objekt" endet.

Zum Beispiel

import * as vscode from 'vscode';

export async function activate(context: vscode.ExtensionContext) {
  // Register the private echo command
  const echoCommand = vscode.commands.registerCommand(
    '_private.command.called.echo',
    (value: string) => {
      return value;
    }
  );
  context.subscriptions.push(echoCommand);
}

Weitere Informationen zur Arbeit mit Befehlen finden Sie im Befehls-API-Leitfaden.

Verwendung der Webview-API

Wie die Zwischenablagen-API wird die Webview-API immer auf dem lokalen Rechner des Benutzers oder im Browser ausgeführt, auch wenn sie von einer Workspace-Erweiterung verwendet wird. Das bedeutet, dass viele webview-basierte Erweiterungen auch in Remote-Workspaces oder Codespaces ordnungsgemäß funktionieren sollten. Es gibt jedoch einige Überlegungen, die Sie beachten sollten, damit Ihre Webview-Erweiterung bei Remote-Ausführung ordnungsgemäß funktioniert.

Verwenden Sie immer asWebviewUri

Sie sollten die API asWebviewUri verwenden, um Erweiterungsressourcen zu verwalten. Die Verwendung dieser API anstelle der fest codierten vscode-resource://-URIs ist erforderlich, um sicherzustellen, dass der browserbasierte Editor von Codespaces mit Ihrer Erweiterung funktioniert. Weitere Informationen finden Sie im Leitfaden zur Webview-API, aber hier ist ein kurzes Beispiel.

Sie können die API in Ihrem Inhalt wie folgt verwenden

// Create the webview
const panel = vscode.window.createWebviewPanel(
  'catWebview',
  'Cat Webview',
  vscode.ViewColumn.One
);

// Get the content Uri
const catGifUri = panel.webview.asWebviewUri(
  vscode.Uri.joinPath(context.extensionUri, 'media', 'cat.gif')
);

// Reference it in your content
panel.webview.html = `<!DOCTYPE html>
<html>
<body>
    <img src="${catGifUri}" width="300" />
</body>
</html>`;

Verwenden Sie die Nachrichtenübermittlungs-API für dynamische Webview-Inhalte

Die VS Code-Webview enthält eine Nachrichtenübermittlungs-API, mit der Sie Ihre Webview-Inhalte dynamisch aktualisieren können, ohne einen lokalen Webserver zu verwenden. Selbst wenn Ihre Erweiterung lokale Webserver ausführt, mit denen Sie interagieren möchten, um Webview-Inhalte zu aktualisieren, können Sie dies von der Erweiterung selbst aus tun, anstatt direkt von Ihrem HTML-Inhalt.

Dies ist ein wichtiges Muster für Remote Development und GitHub Codespaces, um sicherzustellen, dass Ihr Webview-Code sowohl in VS Code als auch im browserbasierten Editor von Codespaces funktioniert.

Warum Nachrichtenübermittlung statt eines localhost-Webservers?

Das alternative Muster ist, Webinhalte in einem iframe bereitzustellen oder Webview-Inhalte direkt mit einem localhost-Server zu interagieren. Standardmäßig wird localhost in einer Webview auf dem lokalen Rechner eines Entwicklers aufgelöst. Das bedeutet, dass für eine remote laufende Workspace-Erweiterung die von ihr erstellten Webviews nicht auf lokale Server zugreifen könnten, die von der Erweiterung gestartet werden. Selbst wenn Sie die IP des Rechners verwenden, werden die Ports, mit denen Sie sich verbinden, in einem Cloud-VM oder einem Container normalerweise standardmäßig blockiert. Selbst wenn dies in VS Code funktionieren würde, würde es im browserbasierten Editor von Codespaces nicht funktionieren.

Hier ist eine Veranschaulichung des Problems bei der Verwendung der Remote - SSH-Erweiterung. Das Problem besteht jedoch auch für Dev Containers und GitHub Codespaces

Wenn möglich, sollten Sie dies vermeiden, da es Ihre Erweiterung erheblich verkompliziert. Die Nachrichtenübermittlungs-API kann denselben Benutzernutzen ohne diese Art von Kopfschmerzen ermöglichen. Die Erweiterung selbst wird auf der Remote-Seite im VS Code Server ausgeführt, sodass sie transparent mit allen Webservern interagieren kann, die Ihre Erweiterung als Ergebnis von Nachrichten von der Webview startet.

Workarounds für die Verwendung von localhost aus einer Webview

Wenn Sie aus irgendeinem Grund die Nachrichtenübermittlungs-API nicht verwenden können, gibt es zwei Optionen, die mit den Remote Development- und GitHub Codespaces-Erweiterungen in VS Code funktionieren.

Jede Option ermöglicht es, Webview-Inhalte über denselben Kanal zu leiten, den VS Code verwendet, um mit dem VS Code Server zu kommunizieren. Wenn wir beispielsweise die Abbildung im vorherigen Abschnitt für Remote - SSH aktualisieren, hätten Sie Folgendes

Option 1 - asExternalUri verwenden

VS Code 1.40 führte die API vscode.env.asExternalUri ein, mit der Erweiterungen lokale http- und https-Anfragen programmatisch remote weiterleiten können. Sie können dieselbe API verwenden, um Anfragen an localhost-Webserver von der Webview weiterzuleiten, wenn Ihre Erweiterung in VS Code ausgeführt wird.

Verwenden Sie die API, um eine vollständige URI für den iframe zu erhalten, und fügen Sie sie zu Ihrem HTML hinzu. Sie müssen auch Skripte in Ihrer Webview aktivieren und eine CSP zu Ihrem HTML-Inhalt hinzufügen.

// Use asExternalUri to get the URI for the web server
const dynamicWebServerPort = await getWebServerPort();
const fullWebServerUri = await vscode.env.asExternalUri(
  vscode.Uri.parse(`https://:${dynamicWebServerPort}`)
);

// Create the webview
const panel = vscode.window.createWebviewPanel(
  'asExternalUriWebview',
  'asExternalUri Example',
  vscode.ViewColumn.One,
  {
    enableScripts: true
  }
);

const cspSource = panel.webview.cspSource;
panel.webview.html = `<!DOCTYPE html>
        <head>
            <meta
                http-equiv="Content-Security-Policy"
                content="default-src 'none'; frame-src ${fullWebServerUri} ${cspSource} https:; img-src ${cspSource} https:; script-src ${cspSource}; style-src ${cspSource};"
            />
        </head>
        <body>
        <!-- All content from the web server must be in an iframe -->
        <iframe src="${fullWebServerUri}">
    </body>
    </html>`;

Beachten Sie, dass alle HTML-Inhalte, die im iframe im obigen Beispiel bereitgestellt werden, relative Pfade verwenden müssen, anstatt localhost fest zu codieren.

Option 2 - Port-Mapping verwenden

Wenn Sie nicht beabsichtigen, den browserbasierten Editor von Codespaces zu unterstützen, können Sie die Option portMapping verwenden, die in der Webview-API verfügbar ist. (Dieser Ansatz funktioniert auch mit Codespaces vom VS Code-Client aus, aber nicht im Browser).

Um eine Port-Zuordnung zu verwenden, übergeben Sie ein portMapping-Objekt, wenn Sie Ihre Webview erstellen

const LOCAL_STATIC_PORT = 3000;
const dynamicServerPort = await getWebServerPort();

// Create webview and pass portMapping in
const panel = vscode.window.createWebviewPanel(
  'remoteMappingExample',
  'Remote Mapping Example',
  vscode.ViewColumn.One,
  {
    portMapping: [
      // This maps localhost:3000 in the webview to the web server port on the remote host.
      { webviewPort: LOCAL_STATIC_PORT, extensionHostPort: dynamicServerPort }
    ]
  }
);

// Reference the port in any full URIs you reference in your HTML.
panel.webview.html = `<!DOCTYPE html>
    <body>
        <!-- This will resolve to the dynamic server port on the remote machine -->
        <img src="https://:${LOCAL_STATIC_PORT}/canvas.png">
    </body>
    </html>`;

In diesem Beispiel werden sowohl im Remote- als auch im lokalen Fall alle Anfragen an https://:3000 automatisch dem dynamischen Port zugeordnet, auf dem ein Express.js-Webserver läuft.

Verwendung nativer Node.js-Module

Native Module, die mit einer VS Code-Erweiterung gebündelt sind (oder dynamisch erworben werden), müssen mit Electron's electron-rebuild neu kompiliert werden. Der VS Code Server führt jedoch eine Standardversion von Node.js (nicht Electron) aus, was dazu führen kann, dass Binärdateien bei der Remote-Verwendung fehlschlagen.

Um dieses Problem zu lösen

1. Schließen Sie beide Sätze von Binärdateien (Electron und Standard-Node.js) für die "Module"-Version in Node.js ein (oder erwerben Sie sie dynamisch), die VS Code bereitstellt.
2. Überprüfen Sie, ob vscode.extensions.getExtension('your.extensionId').extensionKind === vscode.ExtensionKind.Workspace, um die richtigen Binärdateien einzurichten, basierend darauf, ob die Erweiterung remote oder lokal ausgeführt wird.
3. Möglicherweise möchten Sie gleichzeitig Unterstützung für Nicht-x86_64-Hosts oder Alpine-Linux-Container hinzufügen, indem Sie ähnliche Logik befolgen.

Sie können die "Module"-Version, die VS Code verwendet, finden, indem Sie zu Hilfe > Entwicklerwerkzeuge gehen und im Konsolenfenster process.versions.modules eingeben. Um sicherzustellen, dass native Module in verschiedenen Node.js-Umgebungen nahtlos funktionieren, sollten Sie die nativen Module gegen alle möglichen Node.js-"Module"-Versionen und Plattformen kompilieren, die Sie unterstützen möchten (Electron Node.js, offizielles Node.js Windows/Darwin/Linux, alle Versionen). Das Modul node-tree-sitter ist ein gutes Beispiel für ein Modul, das dies gut leistet.

Unterstützung für Nicht-x86_64-Hosts oder Alpine-Linux-Container

Wenn Ihre Erweiterung rein in JavaScript/TypeScript geschrieben ist, müssen Sie möglicherweise nichts tun, um Unterstützung für andere Prozessorarchitekturen oder das musl-basierte Alpine Linux zu Ihrer Erweiterung hinzuzufügen.

Wenn Ihre Erweiterung jedoch auf Debian 9+, Ubuntu 16.04+ oder RHEL / CentOS 7+ Remote-SSH-Hosts, Containern oder WSL funktioniert, aber auf unterstützten Nicht-x86_64-Hosts (z. B. ARMv7l) oder Alpine Linux-Containern fehlschlägt, kann die Erweiterung x86_64 glibc-spezifischen nativen Code oder Laufzeiten enthalten, die auf diesen Architekturen/Betriebssystemen fehlschlagen.

Beispielsweise kann Ihre Erweiterung nur x86_64 kompilierte Versionen von nativen Modulen oder Laufzeiten enthalten. Für Alpine Linux funktionieren der enthaltene native Code oder die Laufzeiten möglicherweise aufgrund grundlegender Unterschiede zwischen der Implementierung von libc in Alpine Linux (musl) und anderen Distributionen (glibc) nicht.

Um dieses Problem zu beheben

1. Wenn Sie kompilierte Codes dynamisch abrufen, können Sie Unterstützung hinzufügen, indem Sie Nicht-x86_64-Ziele mit process.arch erkennen und Versionen herunterladen, die für die richtige Architektur kompiliert wurden. Wenn Sie Binärdateien für alle unterstützten Architekturen in Ihrer Erweiterung einschließen, können Sie diese Logik verwenden, um die richtige zu verwenden.

2. Für Alpine Linux können Sie das Betriebssystem mit await fs.exists('/etc/alpine-release') erkennen und erneut die richtigen Binärdateien für ein musl-basiertes Betriebssystem herunterladen oder verwenden.

3. Wenn Sie diese Plattformen nicht unterstützen möchten, können Sie dieselbe Logik verwenden, um stattdessen eine aussagekräftige Fehlermeldung bereitzustellen.

Es ist wichtig zu beachten, dass einige Drittanbieter-npm-Module nativen Code enthalten, der dieses Problem verursachen kann. In einigen Fällen müssen Sie möglicherweise mit dem Autor des npm-Moduls zusammenarbeiten, um zusätzliche Kompilierungsziele hinzuzufügen.

Vermeiden Sie die Verwendung von Electron-Modulen

Obwohl es praktisch sein kann, sich auf integrierte Electron- oder VS Code-Module zu verlassen, die nicht von der Erweiterungs-API bereitgestellt werden, ist es wichtig zu beachten, dass VS Code Server eine Standardversion (nicht Electron) von Node.js ausführt. Diese Module fehlen bei der Remote-Ausführung. Es gibt einige Ausnahmen, bei denen spezifischer Code vorhanden ist, um sie zum Laufen zu bringen.

Verwenden Sie Basis-Node.js-Module oder Module in Ihrer Erweiterungs-VSIX, um diese Probleme zu vermeiden. Wenn Sie unbedingt ein Electron-Modul verwenden müssen, stellen Sie sicher, dass ein Fallback vorhanden ist, falls das Modul fehlt.

Das folgende Beispiel verwendet das Electron-original-fs-Knotenmodul, falls gefunden, und greift auf das Basis-Node.js-fs-Modul zurück, falls nicht.

function requireWithFallback(electronModule: string, nodeModule: string) {
  try {
    return require(electronModule);
  } catch (err) {}
  return require(nodeModule);
}

const fs = requireWithFallback('original-fs', 'fs');

Versuchen Sie, diese Situationen nach Möglichkeit zu vermeiden.

Bekannte Probleme

Es gibt einige Erweiterungsprobleme, die mit zusätzlichen Funktionalitäten für Workspace-Erweiterungen gelöst werden könnten. Die folgende Tabelle listet bekannte Probleme auf, die in Betracht gezogen werden.

Fragen und Feedback

• Siehe Tipps und Tricks oder die FAQ.
• Suchen Sie nach Antworten auf Stack Overflow.
• Bewerten Sie ein Feature oder fordern Sie ein neues an, durchsuchen Sie bestehende Issues oder melden Sie ein Problem.
• Erstellen Sie eine Development Container-Vorlage oder ein Feature, das andere nutzen können.
• Tragen Sie zu unserer Dokumentation oder zu VS Code bei.
• Details finden Sie in unserem CONTRIBUTING-Leitfaden.