VSCode-Sprachserver – Knoten
Dieses Repository enthält den Code für die folgenden npm-Module:
- vscode-lingualclient : npm-Modul zur Kommunikation mit einem VSCode-Sprachserver über eine VSCode-Erweiterung:
- vscode-Languageserver : NPM-Modul zum Implementieren eines VSCode-Sprachservers mit Node.js als Laufzeit:
- vscode-lingualserver-textdocument : npm-Modul zum Implementieren von Textdokumenten, die auf einem LSP-Server unter Verwendung von Node.js als Laufzeit verwendet werden können:
- vscode-lingualserver-protocol : die tatsächliche Definition des Sprachserverprotokolls in TypeScript:
- vscode-lingualserver-types : Datentypen, die vom Sprachserver-Client und -Server verwendet werden:
- vscode-jsonrpc : das zugrunde liegende Nachrichtenprotokoll zur Kommunikation zwischen einem Client und einem Server:
Alle npm-Module werden mit einer Azure Pipeline erstellt. Sein Status ist:
Klicken Sie hier für ein detailliertes Dokument zur Verwendung dieser npm-Module zur Implementierung von Sprachservern für VSCode.
Mitwirken
Führen Sie nach dem Klonen des Repositorys npm install aus, um Abhängigkeiten zu installieren, und npm run symlink um Pakete in diesem Repository aufeinander zu verweisen.
Geschichte
Weiter (10.0.0-next.* Client und 10.0.0-next.* Server)
- Auf neuere Bibliotheken, Compiler und package.json-Exportregeln aktualisiert:
- Compiler auf
5.5.x aktualisiert. - Bibliotheken hängen jetzt von NodeJS
20.9.0 und es2022 ab. Siehe auch die Knotenzielzuordnung von TypeScript. -
vscode-jsonrpc , vscode-languageserver-protocol , vscode-languageclient und vscode-languageserver verwenden jetzt die exports Eigenschaft, anstatt über eine main und typings Eigenschaft zu verfügen. Dies muss möglicherweise in den tsconfig.json-Dateien rund um module und moduleResolution übernommen werden. Die LSP-Bibliotheken verwenden derzeit node16 für beide Werte.
- vorgeschlagenen CodeActionKind.RefactorMove hinzugefügt
- Snippet-Unterstützung bei Workspace-Bearbeitungen
- Unterstützung zur Kontrolle der Parallelität der Versandanfragen und Benachrichtigungen. Dies ist eine bahnbrechende Änderung, da sie es Benachrichtigungshandlern ermöglicht, ein Versprechen zurückzugeben, dies zu kontrollieren.
- Sorgen Sie dafür, dass die Client-Browser-Implementierung in Bezug auf die Argumente mit der Knoten-Implementierung konsistent ist. Dies ist eine bahnbrechende Änderung, da die Parameterdeklarationen neu angeordnet wurden.
- Der Show-Document-Middleware wurde ein
CancellationToken hinzugefügt, um sie mit der anderen Middleware konsistent zu machen. Dies ist eine bahnbrechende Änderung, da ein erforderlicher Parameter hinzugefügt wurde.
3.17.5 Protokoll, 9.0.1 Client und 9.0.1 Server
3.17.4-Protokoll, 8.2.0 JSON-RPC 9.0.0-Client und 9.0.0-Server
- vorgeschlagene Inline-Vervollständigungsanfrage hinzugefügt.
- Anfrage für vorgeschlagene Formatierungsbereiche hinzugefügt.
- vorgeschlagene Aktualisierungsanforderung für Faltbereiche hinzugefügt. Dadurch hat sich die Form des Faltbereichsfeatures geändert, da wir den Ereignisemitter freilegen müssen. Die Veränderung bricht. Um zum Anbieter zu gelangen, müssen Sie nun Folgendes tun
client . getFeature ( lsclient . FoldingRangeRequest . method ) . getProvider ( document ) ?. provider ;
- diverse Fehlerbehebungen
3.17.4-next.0-Protokoll, 8.2.0-next.0 JSON-RPC, 8.2.0-next.0-Client und 8.2.0-next.0-Server.
- Middleware-Unterstützung für allgemeine Benachrichtigungen und Anfragen sowie für Registrierungs- und Abmeldefunktionen.
- diverse Fehlerbehebungen.
3.17.3 Protokoll, 8.1.0 JSON-RPC, 8.1.0 Client und 8.1.0 Server.
- Unterstützung für benutzerdefinierte Nachrichtenhandler
- diverse Fehlerbehebungen. Bemerkenswert sind Korrekturen für Probleme bei der Bestellung von Anfragen bei vollständiger Dokumentsynchronisierung.
3.17.2 Protokoll, 8.0.2 JSON-RPC, 8.0.2 Client und 8.0.2 Server.
- Machen Sie den Client robuster gegen unerwünschte Neustarts
- Es wurde eine LanguageClient#dispose-Methode hinzugefügt, um einen Client vollständig zu entsorgen
- diverse Fehlerbehebungen.
3.17.0-Protokoll, 8.0.0 JSON-RPC, 8.0.0-Client und 8.0.0-Server.
Bibliotheksspezifische Änderungen sind:
- Bereinigung der
start und stop des Clients. Beide Methoden geben nun ein Versprechen zurück, da diese Methoden asynchron sind. Dies ist eine bahnbrechende Änderung, da start zuvor ein Einwegprodukt zurückgegeben hat. Erweiterungen sollten jetzt eine Deaktivierungsfunktion in ihrer Erweiterungshauptdatei implementieren und das stop aus dem Deaktivierungsaufruf korrekt zurückgeben. Infolgedessen wurde onReady() entfernt, da Erweiterungen jetzt auf den Aufruf start() warten können. Alter Code wie dieser
const client : LanguageClient = ... ;
client . start ( ) ;
await client . onReady ( ) ;
sollte werden:
const client : LanguageClient = ... ;
await client . start ( ) ;
- Die Registrierung von Benachrichtigungen und Anforderungshandlern kann jetzt erfolgen, bevor der Client gestartet wird. Dadurch wird sichergestellt, dass keine Nachrichten vom Server verpasst werden.
- Wenn eine Erweiterung eine Benachrichtigung oder Anfrage sendet, bevor der Client gestartet wurde, wird der Client automatisch gestartet.
- Alle
sendNotification Methoden geben jetzt ein Versprechen zurück. Die Rückgabe eines Versprechens war notwendig, da das eigentliche Schreiben der Nachricht an den zugrunde liegenden Transport asynchron erfolgt und ein Client beispielsweise nicht feststellen konnte, ob eine Benachrichtigung an den Transport übergeben wurde. Dies ist eine bahnbrechende Änderung in dem Sinne, dass sie zu einem schwebenden Versprechen führen und durch einen Linter gekennzeichnet werden könnte. - Alle Handler-Registrierungen geben jetzt ein „Disposable“ zurück, um die Aufhebung der Registrierung des Handlers zu ermöglichen.
- Das Verhalten von
handleFailedRequest hat sich geändert. Anstatt einen Standardwert zurückzugeben, wenn eine Ausnahme vom Server empfangen wird, löst die Methode den Fehler jetzt erneut aus. Dadurch wird sichergestellt, dass das Standardverhalten von VS Code bei Fehlern verwendet wird. Die Methode behandelt RequestCancelled und ServerCancelled auch wie folgt:- Wenn
ServerCancelled empfangen wird und der Client die Anfrage nicht abgebrochen hat, werfen Sie ebenfalls CancellationError, um den Client aufzufordern, die Anfrage erneut auszuführen. - Wenn
RequestCancelled empfangen wird, sollte der Client die Anfrage normalerweise abgebrochen haben und der Code wird den Standardwert zurückgeben (gemäß der besten Interpretation der 3.16-Spezifikation). Wenn der Client nicht abgebrochen hat, interpretieren Sie RequestCancelled als ServerCancelled .
- Der nächste Handler einer Client-Middleware löscht jetzt Serverergebnisse, wenn die Anfrage bereits auf der Clientseite abgebrochen wurde, indem er den Standardwert von VS Code für den entsprechenden Anbieter zurückgibt (meistens
null ). Dies ist eine bahnbrechende Änderung, da die Middleware in früheren Versionen der Bibliothek sehen würde, dass das Ergebnis auch nicht von VS Code verwendet wird. Die Änderung wurde vorgenommen, um CPU und Speicher zu sparen, indem ungenutzte Antwortergebnisse nicht konvertiert werden. - Alle Konverterfunktionen, die ein Array annehmen, sind jetzt asynchron, liefern ein Abbruchtoken und nehmen es entgegen. Dies ist eine bahnbrechende Änderung und wurde eingeführt, um eine Monopolisierung des Erweiterungshosts bei Typkonvertierungen zu vermeiden.
- Der Rückgabetyp von ErrorHandler#error und ErrorHandler#closed hat sich auf bahnbrechende Weise geändert. Es unterstützt jetzt die Rückgabe einer optionalen Nachricht, die dem Benutzer angezeigt wird.
- Unterstützung für Inline-Werte hinzugefügt.
- Unterstützung für Inlay-Hinweise hinzugefügt.
- Unterstützung für Typhierarchien hinzugefügt.
- Unterstützung für Notebook-Dokumente hinzugefügt.
3.16.0-Protokoll, 6.0.0 JSON-RPC, 7.0.0-Client und 7.0.0-Server.
Eine detaillierte Liste der in der Version 3.16.0 des Protokolls vorgenommenen Änderungen finden Sie im Änderungsprotokoll der Spezifikation 3.16.
Bibliotheksspezifische Änderungen sind:
- Bereinigung der Anforderungs- und Benachrichtigungstypen. Der unnötige generische Parameter RO wurde entfernt. Dies ist eine bahnbrechende Veränderung. Zum Anpassen entfernen Sie einfach das Typargument.
- Das neue Konzept eines RegistrationType wurde hinzugefügt, das die Registrierungsmethode von der eigentlichen Anforderungs- oder Benachrichtigungsmethode entkoppelt. Dies ist eine bahnbrechende Änderung für Implementierer benutzerdefinierter Funktionen. Um die
messages anzupassen, benennen Sie sie in registrationType um und geben Sie einen entsprechenden RegistrationType zurück. Entfernen Sie zusätzlich den ersten Parameter aus der register . - Bereinigung von
ErrorCodes . LSP-spezifische Fehlercodes wurden in einen neuen Namespace LSPErrorCodes verschoben. Der Namespace ErrorCodes in jsonrpc ist nicht korrekt für JSON RPC-spezifische Fehlercodes reserviert. Dies ist eine bahnbrechende Veränderung. Um das Problem zu beheben, verwenden Sie stattdessen LSPErrorCodes . - Teilen Sie den Code in Common, Node und Browser auf, um die Verwendung der LSP-Client- und Server-NPM-Module in einem Webbrowser über Webpack zu ermöglichen. Dies ist eine bahnbrechende Änderung und kann zu Kompilierungs-/Laufzeitfehlern führen, wenn sie nicht übernommen wird. Jedes Modul verfügt nun über drei verschiedene Exporte, die die Aufteilung in Common, Node und Browser darstellen. Schauen wir uns
vscode-jsonrpc als Beispiel an: (a) der Import vscode-jsonrpc importiert nur den allgemeinen Code, (b) der Import vscode-jsonrpcnode importiert den allgemeinen Code und den Knotencode und (c) der Import vscode-jsonrpcbrowser importiert den allgemeinen Code und den Browsercode. - Unterstützung hinzugefügt, um die Parameterstruktur beim Senden von Anfragen und Benachrichtigungen in
vscode-jsonrpc zu steuern. Die Parameterstruktur kann mithilfe des zusätzlichen Arguments parameterStructures beim Erstellen eines Anforderungs- oder Benachrichtigungstyps oder beim Senden einer untypisierten Anforderung oder Benachrichtigung mithilfe der Funktion sendRequest oder sendNotification gesteuert werden. Der Standardwert ist ParameterStructures.auto , der Folgendes bewirkt:- Verwenden Sie
byPosition für Nachrichten mit null oder mehr als einem Parameter - Für einen Parameter wurde
byName für Parameter verwendet, bei denen es sich um Objektliterale handelt. Verwendet byPosition für alle anderen Parameter.
3.15.3 Protokoll, 6.1.x-Client und 6.1.x-Server
- Kleine Änderungen an der vorgeschlagenen Unterstützung für semantische Token.
3.15.2 Protokoll, 6.1.x-Client und 6.1.x-Server
- Vorgeschlagene Unterstützung für semantische Token.
3.15.0-Protokoll, 6.0.0-Client und 6.0.0-Server
- Fortschrittsunterstützung für geleistete Arbeit und Teilergebnisfortschritt.
- Vorgeschlagene Implementierung für Anrufhierarchien.
-
SelectionRangeRequest Protokoll hinzugefügt:- Neue APIs in Typen:
SelectionRange - Neue APIs im Protokoll:
SelectionRangeRequest , SelectionRangeParams , SelectionRangeClientCapabilities , SelectionRangeServerCapabilities , SelectionRangeProviderOptions ,
- Unterstützung für benutzerdefinierte Textdokumentimplementierungen:
- Neues NPM-Paket
vscode-languageserver-textdocument , das eine Standard-Textdokumentimplementierung mit grundlegender inkrementeller Aktualisierung bereitstellt. Der Server muss nun dieses NPM-Paket vorab benötigen. - Veraltete Textdokumentimplementierung in Typen.
- Dies führte zu einem kleinen Bruch auf der Serverseite. Anstatt
new TextDocuments zu erstellen, müssen Sie jetzt eine Textdokumentkonfiguration übergeben, um Rückrufe zum Erstellen und Aktualisieren eines Textdokuments bereitzustellen. Hier finden Sie Beispiele in TypeScript und JavaScript
import { TextDocuments } from 'vscode-languageserver' ;
import { TextDocument } from 'vscode-languageserver-textdocument' ;
const documents = new TextDocuments ( TextDocument ) ; const server = require ( "vscode-languageserver" ) ;
const textDocument = require ( "vscode-languageserver-textdocument" ) ;
const documents = new server . TextDocuments ( textDocument . TextDocument ) ;
5.1.1 Kunde
- Behebt, dass der [textDocument/rename]-Client beim Registrieren des Anbieters
RenameOptions nicht befolgt
5.1.0-Client und 5.1.0-Server
- Übernehmen Sie die Protokollversion 3.13.0
3.13.0 Protokoll
-
FoldingRangeRequestParam wurde in „FoldingRangeParams“ umbenannt ( FoldingRangeRequestParam wird aus Gründen der Abwärtskompatibilität weiterhin bereitgestellt) - Unterstützung für Vorgänge zum Erstellen, Umbenennen und Löschen von Dateien in Arbeitsbereichsbearbeitungen hinzugefügt.
5.0.0-Client und 5.0.0-Server
- Sorgen Sie dafür, dass der Client mit Electron 2.x funktioniert. welches seit VS Code 1.26.x verwendet wird
- Überprüfen Sie, ob die erwartete Client-Version, die in
engines.vscode in der Datei package.json angegeben ist, mit der VS-Code-Version übereinstimmt, auf der der Client ausgeführt wird.
4.4.0 Client & 4.4.0 Server & 3.10.0 Protokoll
- Implementieren Sie eine hierarchische Dokumentgliederung
-
Color , ColorInformation , ColorPresentation wurden nach Types verschoben -
FoldingRangeRequest -Protokoll hinzugefügt:- Neue APIs in Typen:
FoldingRange , FoldingRangeKind - Neue APIs im Protokoll:
FoldingRangeRequest , FoldingRangeRequestParam , FoldingRangeClientCapabilities , FoldingRangeServerCapabilities , FoldingRangeProviderOptions ,
4.3.0 Client & 4.3.0 Server & 3.9.0 Protokoll
- Unterstützung für
preselect Eigenschaft für CompletionItem hinzufügen
4.2.0 Client & 4.2.0 Server & 3.8.0 Protokoll
- CodeAction-Klasse hinzufügen
- Fügen Sie Unterstützung für Code-Aktionsliterale als Rückgabewert der textDocument/codeAction-Anfrage hinzu
4.1.4 Client und 4.1.3 Server
- Client: Nach dem Neustart des Servers werden doppelte Nachrichten gesendet
4.1.1 Kunde
- Informationen zum Serverabsturz gehen verloren, da der Ausgabekanal geschlossen wird
4.1.0 Client und Server
Fügen Sie Unterstützung für verwandte Informationen in der Diagnose hinzu.
Initialisierungsausnahmen wurden verschluckt
Fehler beim Umbenennen werden in VSCode immer noch nicht angezeigt
termineProcess.sh wird nicht im dist-Paket geliefert
Fügen Sie Middleware hinzu, um textDocument/publishDiagnostics abzufangen
4.0.1 Kunde
- Unnötige Konsolenprotokollanweisung entfernt.
4.0.0 Server und Client
- implementierte die neuesten Protokollergänzungen. Bemerkenswert sind der Vervollständigungskontext, das erweiterbare Vervollständigungselement und die Symbolart sowie die Markdown-Unterstützung für Vervollständigungselement- und Signaturhilfe. Auf Version 4.0.0 verschoben, da die Einführung des Vervollständigungskontexts eine grundlegende Änderung in der Client-Middleware erforderte. Die alte Signatur:
provideCompletionItem?: ( this : void , document : TextDocument , position : VPosition , token : CancellationToken , next : ProvideCompletionItemsSignature ) => ProviderResult < VCompletionItem [ ] | VCompletionList > ;
enthält nun ein zusätzliches Argument context :
provideCompletionItem?: ( this : void , document : TextDocument , position : VPosition , context : VCompletionContext , token : CancellationToken , next : ProvideCompletionItemsSignature ) => ProviderResult < VCompletionItem [ ] | VCompletionList > ;
- Bemerkenswerte Korrekturen:
- Wert erhalten, nachdem der Befehl programmgesteuert ausgeführt wurde
- Erleben Sie eine unendliche Rekursion in diesem Code in VSCode 1.18.1
- LanguageClient#handleConnectionClosed kann nicht neu gestartet werden, wenn this._resolvedConnection.dispose() ausgelöst wird
6.0.0 Server und Client
- Wechseln Sie zu Protokoll 3.15.0
- JS-Ziel auf ES2017 verschieben
3.15.0 Typen und Protokoll
- Implementieren Sie LSP 3.15.0
3.6.1 Typen
- ESM als Ausgabeformat hinzugefügt (für Webpack und andere ESM-Konsumenten)
3.5.0 Server und Client
- Erlauben Sie dem Client, den Server im getrennten Modus zu starten. Wenn der Server getrennt ausgeführt wird, überwacht der Client den Serverprozess nicht und bricht ihn beim Herunterfahren ab.
- Fehlerbehebung.
3.4.0 Server und Client
- Es wurde ein neues NPM-Modul
vscode-languageserver-protocol hinzugefügt, das die Protokolldefinitionen in TypeScript enthält. Dieses Modul wird jetzt vom Client und vom Server gemeinsam genutzt. - Den
protocol , client und server NPM-Modulen wurde Unterstützung für das vorgeschlagene Protokoll hinzugefügt. Das vorgeschlagene Protokoll kann sich ändern, auch wenn es in einer stabilen Version der npm-Module ausgeliefert wird. - Das vorgeschlagene Protokoll wurde für die folgenden Funktionen hinzugefügt:
- Konfiguration : Unterstützung zum Abrufen von Konfigurationseinstellungen durch Senden einer Anfrage vom Server an den Client
- workspaceFolders : Unterstützung für die Verarbeitung von mehr als einem Stammordner pro Arbeitsbereich
- colorProvider : Unterstützung zum Berechnen von Farbbereichen für ein Dokument
3.3.0 Server und Client
- Der Client wurde in einen Basis-Client und einen Haupt-Client aufgeteilt, um die Wiederverwendung der Client-Implementierung in anderen Umgebungen zu unterstützen.
- Die Anforderungsverarbeitung wurde asynchroner gestaltet. Anstatt also eine Anfrage sofort zu verarbeiten, wenn der Code durch einen Node.js-Rückruf benachrichtigt wird, wird die Anfrage nun in eine Warteschlange gestellt und aus der Warteschlange verarbeitet. Dies ermöglicht bei Bedarf ein besseres Löschen oder Falten von Ereignissen.
- Fehlerbehebungen siehe April und Mai
3.2.1 Server und Client
- Behoben: Verwendung eines falschen Namens für die Methode
client/registerFeature : sollte client/registerCapability lauten
3.2.0 Server und Client
-
WorkspaceEdit entspricht der 3.x-Version der Spezifikation und ist abwärtskompatibel mit der 2.x-Version der Bibliothek. -
RequestCancelled Fehlercode hinzugefügt. - Behoben, dass nodePath nicht funktioniert (vscode-tslint)
- Das Update von 3.0.4/3.0.5 auf 3.1.0 hat meine Erweiterung beschädigt
3.1.0 Server und Client
- Unterstützung für Named Pipes und Socket-Dateitransport hinzufügen
- Dead-Lock-Problem mit Node-IPC behoben.
3.0.5 Server und 3.0.4 Client
- veraltete
Files.uriToFilePath zugunsten des vscode-uri npm-Moduls, das eine vollständigere Implementierung von URI für VS Code bietet. -
rootPath optional gemacht, da es in 3.x veraltet ist.
3.0.3: Client, Server und JSON-RPC
Neue Funktionen
- Alle Bibliotheken nach TypeScript 2.xx verschoben
- Client und Server sind auf ES6 kompiliert. JSON-RPC ist weiterhin auf ES5 kompiliert.
- JSON-RPC unterstützt n Parameteranforderungen und Benachrichtigungsaufrufe.
- Unterstützung für die Version 3.0 des Language Server-Protokolls. Einige Highlights sind:
- Unterstützung für Feature-Flags.
- Unterstützung für dynamische Registrierung. In der 2.x-Version der Bibliothek gab ein Server seine Fähigkeiten statisch bekannt. In 3.x kann der Server nun mithilfe der neuen Anforderungen
client/registerCapability und client/unregisterCapability Capability-Handler dynamisch registrieren und die Registrierung aufheben. - Unterstützung für die Delegierung der Befehlsausführung über einen neuen Anforderungsworkspace
workspace/executeCommand an den Server.
- Unterstützung für Snippets in Vervollständigungselementen:
- Neuer Typ
InsertTextFormat - CompletionItem.insertTextFormat steuert, ob der eingefügte Test als einfacher Text oder als Snippet interpretiert wird.
Wichtige Änderungen:
- Um eine geordnete Zustellung von Benachrichtigungen und Anfragen sicherzustellen, löst der Sprachclient jetzt aus, wenn sendRequest, onRequest, sendNotification oder onNotification aufgerufen wird, bevor der Client bereit ist. Verwenden Sie das Versprechen onReady(), um zu warten, bis der Client bereit ist.
let client = new LanguageClient ( ... ) ;
client . onReady ( ) . then ( ( ) => {
client . onNotification ( ... ) ;
client . sendRequest ( ... ) ;
) ;- Die veralteten Modulfunktionen auf den Konvertern code2Protocol und Protocol2Code wurden entfernt. Verwenden Sie stattdessen die entsprechenden Eigenschaften der LanguageClient-Instanz, um Zugriff auf dieselben Konverter zu erhalten, die vom LanguageClient verwendet werden.
// Old
import { Protocol2Code , ... } from 'vscode-languageclient' ;
Protocol2Code . asTextEdits ( edits ) ;
// New
let client = new LanguageClient ( ... ) ;
client . protocol2CodeConverter . asTextEdits ( edits ) ;- Aufgrund der Verwendung von TypeScript 2.xx und der Unterschiede in der d.ts-Generation müssen Benutzer der neuen Version ebenfalls auf TypeScript 2.xx umsteigen. Normalerweise wird der
LanguageClient in einer VS Code-Erweiterung verwendet. Ausführliche Schritte zum Upgrade einer VS Code-Erweiterung auf TypeScript 2.xx finden Sie hier. -
activeSignature und activeParameter wurden in SignatureHelp fälschlicherweise als optional deklariert. Mittlerweile sind sie Pflicht. - Die Datei
protocol.ts verwendete Enum-Typen in 2.x. Das Protokoll selbst basiert jedoch auf Zahlen, da keine Annahme über das Vorhandensein eines Aufzählungstyps in der implementierenden Sprache getroffen werden kann. Um dies klarer zu machen, wurde die Aufzählung durch Zahlentypen durch eine or-Literal-Typdefinition ersetzt. Dies kann zu Kompilierungsfehlern führen, wenn eine Zahl ohne ordnungsgemäße Bereichsprüfung direkt einem vorherigen Aufzählungstyp zugewiesen wurde. - Anforderungs- und Benachrichtigungstypen sind jetzt Klassen statt Schnittstellen. Darüber hinaus benötigen sie jetzt ein zusätzliches Typargument, um die Registrierungsoptionen für die dynamische Registrierung einzugeben. Es ist ganz einfach, sich an diese Veränderung anzupassen. Erneuern Sie einfach den
RequestType oder NotificationType und fügen Sie void als Registrierungsoptionstyp hinzu. Bitte denken Sie daran, dies sowohl auf der Client- als auch auf der Serverseite zu aktualisieren:
// Old
export namespace MyRequest {
export const type : RequestType < MyParams , MyResult , void > = { get method ( ) { return 'myRequest' ; } } ;
}
export namespace MyNotification {
export const type : NotificationType < MyParams > = { get method ( ) { return 'myNotification' ; } } ;
}
// New
export namespace MyRequest {
export const type = new RequestType < MyParams , MyResult , void , void > ( 'myRequest' ) ;
}
export namespace MyNotification {
export const type = new NotificationType < MyParams , void > ( 'myNotification' ) ;
} 2.6.0: Client und Server
- Unterstützung für Dokument-Link-Anbieter
- Unterstützung für zusätzliche Textbearbeitungen und Befehle in Vervollständigungselementen.
2.5.0: Client und Server
- Bessere Fehlerbehandlung auf Client-Seite.
- Ereignisse zum Starten und Stoppen des Servers.
- Als Funktion können Initialisierungsoptionen bereitgestellt werden.
- Unterstützung für stdio/stderr-Codierung.
- Unterstützung für die Konvertierung von URIs zwischen dem Client und dem Server.
- Die Protokollierung der Serververbindung.konsole wird jetzt im entsprechenden Ausgabekanal statt in der Entwicklerkonsole angezeigt.
- Wenn zwischen Client und Server ein Nicht-Standard-Kommunikationskanal verwendet wird, wird der Standard des Servers auf den Ausgabekanal umgeleitet.
- Ein Client kann jetzt eine ID und einen Namen haben.
2.4.0 Client und Server
- Datentypen wie Range, Position, TextDocument, Hover, CompletionItem ... wurden in das neue Knotenmodul vscode-Languageserver-Types extrahiert. Das neue Knotenmodul wird zwischen Server und Client gemeinsam genutzt und kann auch von Sprachdienstbibliotheken verwendet werden, die dieselben Datentypen verwenden möchten.
2.3.0: Nur Client
- Der Client startet nun den Server neu, wenn der Server abstürzt, ohne dass zuvor eine Exit-Benachrichtigung gesendet wurde. Die zum Neustart des Servers verwendete Strategie ist anpassbar (siehe
LanguageClientOptions.errorHandler ). Die Standardstrategie startet den Server neu, es sei denn, er ist in den letzten 3 Minuten fünfmal oder öfter abgestürzt.
2.0: Eine ausführliche Beschreibung der Version 2.0 finden Sie hier. Eine Zusammenfassung der Änderungen:
- Unterstützung bei der Stornierung von Anfragen. Die Stornierung wird automatisch mit den Stornierungstoken von VSCode verknüpft
- Benachrichtigung zum Speichern des Dokuments.
- Synchronisierte Textdokumente tragen die Versionsnummer des Textdokuments von VSCode
1.1.x: Stellt alle im Erweiterungshost verfügbaren Sprachdienstfunktionen über das Sprach-Client/Server-Protokoll bereit. Hinzugefügte Funktionen:
- Codeaktionen: Bereitstellung von Aktionen zur Behebung von Diagnoseproblemen.
- Code Lens: Stellen Sie Befehle bereit, die zusammen mit dem Quelltext angezeigt werden.
- Formatierung: gesamtes Dokument, Dokumentbereiche und Formatierung nach Typ.
- Refactoring umbenennen: Bietet Umbenennungssymbole.
1.0.x: Version, die die folgenden Funktionen unterstützt:
- Transporte: stdio und node IPC können als Transportmittel verwendet werden.
- Dokumentsynchronisierung: inkrementelle und Volltextdokumentsynchronisierung.
- Konfigurationssynchronisierung: Synchronisierung der Konfigurationseinstellungen mit dem Server.
- Dateiereignisse: Synchronisierung von Dateiereignissen mit dem Server.
- Code Complete: Bietet Code-Komplettlisten.
- Dokumenthervorhebungen: Hebt alle „gleichen“ Symbole in einem Textdokument hervor.
- Hover: Stellt Hover-Informationen für ein in einem Textdokument ausgewähltes Symbol bereit.
- Signaturhilfe: Bietet Signaturhilfe für ein in einem Textdokument ausgewähltes Symbol.
- Gehe zu Definition: Bietet Gehe-Definitionsunterstützung für ein in einem Textdokument ausgewähltes Symbol.
- Referenzen suchen: Findet alle projektweiten Referenzen für ein in einem Textdokument ausgewähltes Symbol.
- Dokumentsymbole auflisten: Listet alle in einem Textdokument definierten Symbole auf.
- Arbeitsbereichssymbole auflisten: Listet alle projektweiten Symbole auf.
0.10.x: Erste Versionen zum Aufbau einer guten API für die Client- und Serverseite
Lizenz
MIT
