gopls 0.24 brings interactive refactoring, with a proposal to add dialogs to the LSP

Serguey Asael Shinder17 October 2026, 08:322 min read

The Go team has introduced interactive refactoring in gopls, the Go language server, in a post on the Go blog on 16 October 2026 by Hongxiang Jiang. The feature lets a code action open dialogs in the editor and collect answers before any edit is computed. Working support ships in gopls v0.24.0 and in the official Go extension for VS Code v0.56.0.

The problem it solves. In the Language Server Protocol (LSP), almost every code transformation behaves like a function with no parameters: the user triggers it and the server computes the edits from the cursor position and the syntax tree. Renaming is the one exception, and it needed its own PrepareRename call. When the context is not enough, a server can only apply a fixed default or not offer the action. The post's example: "Add struct tags" in gopls always produced json tags in camelCase, because there was no way to ask.

The proposal. Rather than embedding dialog logic in individual editors, which leaves out editors such as Neovim and Emacs that stick closely to the protocol, the team wrote a proposal for the LSP itself, microsoft/language-server-protocol#1164. It was designed together with the Dart team and is meant as an open mechanism for any language and any editor. A design document covers the stateless form protocol and the alternatives that were considered.

What it does in gopls today.

• Add struct tags (since v0.23.0) first asks which tags to add, pre-filled with json and accepting combinations such as json,yaml,db, then which naming convention to use (camelCase, snake_case, PascalCase).
• Remove struct tags asks which keys to delete, so db tags can go while json tags stay.
• Implement an interface (since v0.23.0) asks for the interface name, with live completion over the workspace and the standard library (for example maphash.Hasher). For generic interfaces it then asks for each type argument and generates the method stubs.
• Move declaration is shown as a preview "scheduled for an upcoming gopls release". A file picker chooses the destination; the declaration moves together with the helpers only it uses, references are updated and imports are cleaned up in both files.

gopls v0.24.0 also includes a "Slay the dragon" action on a package-level variable named dragonSlayer, intended as a self-contained test case for editor authors implementing multi-step dialogs.

Next. The roadmap names Change Signature (golang/go#38028), which needs input such as the new parameter order and a default argument for existing call sites; interactive conflict resolution when a rename would shadow or collide; and interactive commands that are not edits at all, such as configuring test or benchmark runs with profiling flags. Proof-of-concept client integrations have been explored for Neovim and Emacs; feedback goes to the Go issue tracker and the LSP discussion.

Source: The Go Blog, "Interactive refactoring in gopls" — https://go.dev/blog/interactive-refactoring