gopls 0.24 bringt interaktives Refactoring – samt Vorschlag für Dialoge im LSP

Serguey Asael Shinder17 October 2026, 08:322 Min. Lesezeit

Das Go-Team hat interaktives Refactoring in gopls vorgestellt, dem Language Server für Go. Der Beitrag von Hongxiang Jiang erschien am 16. Oktober 2026 im Go-Blog. Eine Code-Aktion kann damit im Editor Dialoge öffnen und Antworten einsammeln, bevor die Änderungen berechnet werden. Lauffähig ist das in gopls v0.24.0 und in der offiziellen Go-Erweiterung für VS Code v0.56.0.

Das Problem. Im Language Server Protocol (LSP) verhält sich fast jede Code-Transformation wie eine Funktion ohne Parameter: Man löst sie aus, und der Server berechnet die Änderungen aus Cursorposition und Syntaxbaum. Einzige Ausnahme ist das Umbenennen, das dafür einen eigenen Aufruf PrepareRename braucht. Reicht der Kontext nicht, bleibt dem Server nur ein fester Standard oder der Verzicht auf die Aktion. Das Beispiel aus dem Beitrag: „Add struct tags“ erzeugte in gopls immer json-Tags in camelCase, weil es keinen Weg gab, nachzufragen.

Der Vorschlag. Statt Dialoglogik in einzelne Editoren einzubauen – was Editoren wie Neovim und Emacs außen vor lässt, die sich eng an das Protokoll halten –, hat das Team einen Vorschlag für das LSP selbst eingereicht: microsoft/language-server-protocol#1164. Entstanden ist er gemeinsam mit dem Dart-Team, gedacht ist er als offener Mechanismus für alle Sprachen und Editoren. Ein Designdokument beschreibt das zustandslose Formularprotokoll und die verworfenen Alternativen.

Was gopls heute damit macht.

• Add struct tags (seit v0.23.0) fragt zuerst, welche Tags hinzukommen – vorbelegt mit json, Kombinationen wie json,yaml,db sind möglich –, dann nach der Namenskonvention (camelCase, snake_case, PascalCase).
• Remove struct tags fragt, welche Schlüssel entfernt werden sollen; so können db-Tags verschwinden und json-Tags bleiben.
• Interface implementieren (seit v0.23.0) fragt nach dem Namen des Interfaces, mit Live-Vervollständigung über Workspace und Standardbibliothek (etwa maphash.Hasher). Bei generischen Interfaces folgt die Frage nach jedem Typargument, danach entstehen die Methoden-Stubs.
• Deklaration verschieben ist als Vorschau zu sehen und „für ein kommendes gopls-Release geplant“. Ein Dateidialog wählt das Ziel; die Deklaration wandert mit den Hilfsdeklarationen, die nur sie nutzt, Referenzen werden angepasst und Importe in beiden Dateien bereinigt.

gopls v0.24.0 enthält zudem eine Aktion „Slay the dragon“ auf einer Paketvariablen namens dragonSlayer – als in sich geschlossener Testfall für Editor-Autoren, die mehrstufige Dialoge umsetzen.

Wie es weitergeht. Auf der Roadmap stehen Change Signature (golang/go#38028), das Eingaben wie die neue Parameterreihenfolge und ein Standardargument für bestehende Aufrufe braucht, interaktive Konfliktlösung, wenn eine Umbenennung Namen verdecken oder kollidieren würde, und interaktive Befehle ohne Code-Änderung, etwa die Konfiguration von Test- oder Benchmarkläufen mit Profiling-Flags. Für Neovim und Emacs wurden Client-Integrationen als Machbarkeitsstudie erprobt; Rückmeldungen nimmt der Go-Issue-Tracker und die LSP-Diskussion entgegen.

Quelle: The Go Blog, „Interactive refactoring in gopls“ — https://go.dev/blog/interactive-refactoring