Ein gemeinsames Protokoll für Programmiersprachen

27. Juni 2016 von Das VS Code Team, @code

Visual Studio Code ist ein Editor für jeden Entwickler, unabhängig von der verwendeten Programmiersprache. Zwischen den im Tool integrierten Sprachen oder den Erweiterungen im Marketplace unterstützen wir über 150 Sprachen. Wir sind auch bestrebt, VS Code offen zu entwickeln und die Komponenten, die VS Code antreiben, verfügbar und Open Source zu machen. Eine unserer bemerkenswertesten Komponenten ist der Monaco Editor, aber eine weitere Technologie, die VS Code antreibt, ist ein offenes, JSON-basiertes Protokoll, das jeder nutzen kann, um Unterstützung für eine neue Programmiersprache zu VS Code hinzuzufügen, indem ein "Language Server" implementiert wird.

Jede Sprache, jedes Tool

Heute auf der DevNation Konferenz in San Francisco haben wir zusammen mit Red Hat und Codenvy angekündigt, dass dieses Language Server Protokoll nun von Tool-Erstellern und Sprach-Anbietern branchenweit übernommen wird. Für Sprach-Ersteller bedeutet dies eine verbesserte Tooling-Erfahrung für ihre Sprache auf einer Vielzahl von Entwicklungswerkzeugen und Betriebssystemen, ähnlich der Erfahrung, die TypeScript-Entwickler oder C#-Entwickler (über OmniSharp) heute erhalten. Es bedeutet auch, dass jeder Entwickler eine konsistente Editor-Erfahrung für seine bevorzugte Programmiersprache auf jedem Tool haben kann – auch wenn dieses Tool nicht VS Code ist.

Wie es funktioniert

Visual Studio Code bietet eine umfangreiche Sprachunterstützung für viele Programmiersprachen. Die Unterstützung für eine bestimmte Programmiersprache wird von einem Language Server bereitgestellt, der ein tiefes Verständnis für diese Sprache hat. VS Code kommuniziert mit diesen Servern, um umfangreiche Bearbeitungsfunktionen wie 'Fehler & Warnungen', 'Refactoring' und 'Zur Definition gehen' zu ermöglichen.

Hier ist ein Beispiel dafür, wie ein Tool und ein Language Server semantische Informationen während einer routinemäßigen Bearbeitungssitzung austauschen könnten

• Der Benutzer öffnet eine Datei (bezeichnet als Dokument) im Tool: Das Tool benachrichtigt den Language Server, dass ein Dokument geöffnet ist (didOpen) und dass die Informationen zu diesem Dokument vom Tool im Speicher gehalten werden.

• Der Benutzer nimmt Änderungen vor: Das Tool benachrichtigt den Server über die Dokumentenänderung (didChange) und die semantischen Informationen des Programms werden vom Language Server aktualisiert. Während dies geschieht, analysiert der Language Server diese Informationen und benachrichtigt das Tool über die gefundenen Fehler und Warnungen (diagnostics).

• Der Benutzer führt 'Zur Definition gehen' für ein Symbol aus: Das Tool sendet eine definition Anfrage an den Server. Der Server antwortet mit einer uri des Dokuments, das die Definition enthält, und dem range innerhalb des Dokuments. Basierend auf diesen Informationen kann das Tool das entsprechende Dokument an der definierenden Position öffnen.

• Der Benutzer schließt das Dokument (Datei): Eine didClose Benachrichtigung wird vom Tool gesendet, die den Language Server darüber informiert, dass das Dokument nicht mehr im Speicher ist und stattdessen vom Dateisystem verwaltet wird (d.h. darauf gespeichert ist).

Diese Kommunikation, die über JSON-RPC stattfindet, erfolgt im Laufe einer typischen Sitzung viele Male.

Diese Architektur ermöglicht es VS Code, mit mehreren Language Servern zu interagieren, von denen jeder in jeder Sprache implementiert sein kann (unabhängig von der Sprache, in der das Tool implementiert wurde), und eine Vielzahl von Funktionen unterstützt, solange es das gemeinsame JSON-basierte Protokoll nutzt.

Es ermöglicht auch, dass ein bestimmter Language Server einmal implementiert wird und verschiedene Tools ihn nutzen können. Deshalb ist es spannend, dass das Protokoll von Codenvy übernommen wurde, die es in die Eclipse IDE der nächsten Generation, Eclipse Che, integriert haben, sowie von Red Hat, die daran arbeiten, einen eigenständigen Language Server für Java zu veröffentlichen, der von jedem Tool genutzt werden kann, das das Protokoll verwendet.

Offene Spezifikation

Die vollständige Spezifikation für dieses Protokoll ist in einem öffentlichen GitHub-Repository verfügbar, ebenso wie eine Historie der Entwicklung des Protokolls bis heute. Da es weiterhin von mehr Sprachen und Tools übernommen wird, beabsichtigen wir, das Protokoll zusammen mit Partnern wie Red Hat, Codenvy und anderen in der Open-Source-Community zu unterstützen und weiterzuentwickeln. Jeder kann Fragen stellen, Issues melden oder Pull Requests auf dem Repository einreichen, genau wie bei jedem anderen Open-Source-Projekt.

Was kommt als Nächstes

Dies ist erst der Anfang – Gemeinschaften für Programmiersprachen wie OmniSharp (C#), JSON, C++, xText, JavaFX und R haben sich verpflichtet, in Zukunft Language Server für ihre Sprachen zu veröffentlichen. Eine vollständige Liste der Protokollimplementierungen, einschließlich Language Server, Editoren und SDKs, ist im GitHub-Repository verfügbar.

Wenn Sie mehr erfahren möchten, sehen Sie sich die Breakout-Session an, lesen Sie die Blogbeiträge von Red Hat und dem Eclipse Che-Team und besuchen Sie das Language Server Protocol Repository auf GitHub. Es gibt sogar einen Language Server Walkthrough, bei dem Sie den Quellcode eines funktionierenden Language Servers, der in TypeScript und Node.js implementiert ist, durchgehen können. Aber natürlich können Sie einen Language Server in jeder Sprache implementieren!

Viel Spaß beim Programmieren!

Das VS Code Team, @code