Hongxiang Jiang\n16 October 2026
\nWhen editing code in a modern IDE or editor, developers rely on its refactoring\nfeatures to automate common transformations. Today, we are excited to introduce\ninteractive refactoring in gopls, powered by a new capability we are\nproposing for the Language Server Protocol (LSP)\nthat brings dynamic, multi-step dialogs directly into your favorite editor.\nCrucially, we designed this capability (in collaboration with the Dart team)\nnot just for Go, but as an open standard for all programming languages and\neditor ecosystems. Working support is already available in gopls v0.24.0 and\nthe official Go extension for VS Code v0.56.0.
\nThe LSP is an open standard that decouples language-specific\nfeatures from specific text editors. As you navigate and edit code, your\neditor (such as VS Code, Neovim, or Emacs) and a language server (like gopls)\nengage in a continuous JSON-RPC exchange to provide features like autocomplete,\nhover documentation, diagnostics, and code actions.
\nToday, almost every code transformation in the LSP is like a function of no\nparameters: you trigger the operation, and the server immediately computes the\nedits. (Renaming a symbol is the sole exception: because it is a function of one\nparameter, the desired new name, it required its own dedicated PrepareRename\nRPC in the protocol.)
"Add struct tags", without questions
\nThe language server must deduce the user’s intent from context alone, namely\nthe cursor position and the enclosing syntax tree. When that context is not\nenough, the server is forced into one of two choices: apply a one-size-fits-all\ndefault, or refrain from offering the transformation altogether. The limitation\nlies not in gopls’s ability to compute the necessary edits, but in the\nLSP’s lack of a mechanism for language servers to ask the user for input.
\nFor many transformations, this parameterless model works well. But many others\nneed additional input from the user: which struct tags to add and in what\nnaming convention, which interface to implement, which file to move a\ndeclaration to. Without a way to ask, gopls could only guess—“Add struct\ntags”, for example, always produced json tags in camelCase—or not offer the\nrefactoring at all. With interactive refactoring, language servers can now\neasily provide new operations with one or more parameters.
"Add struct tags", with questions
\nWhile some language extensions have worked around this limitation by embedding\ncustom, language-specific dialog logic directly into individual editors, doing\nso leaves behind other editors (such as Neovim and Emacs) that stick strictly\nto the LSP with minimal custom client code. More importantly, editor-specific\nworkarounds go against the fundamental purpose of the LSP: to decouple\nlanguage-specific features from editors so that each server improvement benefits\nevery client.
\nOur LSP interactive refactoring proposal\n(microsoft/language-server-protocol#1164)\nsolves this by establishing a standard mechanism for\nlanguage servers to collect user input before computing text edits. For Go\ndevelopers, this unlocks a suite of long-awaited refactorings, including:
\namong many others.
\nAdding and removing struct tags (gopls v0.23.0)
\nWhen configuring serialization formats, developers frequently need custom tags\nand casing conventions. Previously, running “Add struct tags” unconditionally\ninjected json tags using camelCase formatting.
With interactive refactoring:
\nPlace your cursor on any struct definition and select the
“Add struct tags” code action.
An input dialog appears, pre-filled with json, allowing you to customize
any combination of tags (such as json,yaml,db).
A second dialog lets you select your desired naming convention (such as
camelCase, snake_case, or PascalCase).
Gopls generates and applies the formatted struct tags across your type
definition.
Interactive "Add struct tags" in VS Code
\nHere is the before-and-after transformation:
\ntype UserProfile struct {\n ID int64\n FirstName string\n LastName string\n EmailAddr string\n}type UserProfile struct {\n ID int64 `json:"id" db:"id"`\n FirstName string `json:"first_name" db:"first_name"`\n LastName string `json:"last_name" db:"last_name"`\n EmailAddr string `json:"email_addr" db:"email_addr"`\n}Similarly, “Remove struct tags” now asks you for the specific tag keys\nyou wish to delete (for example, removing only db tags while preserving the json\ntag), rather than wiping out all struct tags indiscriminately.
Interactive "Remove struct tags" in VS Code
\nImplementing interfaces with dynamic symbol search
\nWhen creating a type to satisfy an interface, developers previously had to copy\nthe interface declaration and manually turn it into a set of methods on the\nreceiver type (or rely on external tools like impl by manually typing the\nreceiver and qualifying the name of the interface).
Since gopls v0.23.0, with interactive refactoring:
\nPlace your cursor on any concrete type and select the
“Add methods to X to implement an interface…” code action.
A text entry field appears, inviting you to choose the name of an interface
type. It makes dynamic queries to gopls to auto-complete names of types in\n your workspace and the standard library (for example, maphash.Hasher).
If the selected interface has type parameters, gopls asks for a
concrete type argument for each type parameter (such as Foo).
Gopls generates complete method stubs with appropriate receiver names and
instantiated method signatures.
*Interactive "Add methods to implement an interface..." in\nVS Code*
\ntype Foo struct{}\n\ntype MyHasher struct{}type Foo struct{}\n\ntype MyHasher struct{}\n\n// Equal implements [maphash.Hasher].\nfunc (m *MyHasher) Equal(x Foo, y Foo) bool {\n panic("unimplemented")\n}\n\n// Hash implements [maphash.Hasher].\nfunc (m *MyHasher) Hash(*maphash.Hash, Foo) {\n panic("unimplemented")\n}Moving declarations across files and packages (preview)
\nMoving declarations manually by cutting and pasting can easily break references\nand requires tedious import cleanup across multiple files. While scheduled for\nan upcoming gopls release, our working implementation already demonstrates how\ninteractive file selection streamlines cross-file and cross-package moves:
\nPlace your cursor on any top-level declaration and select the
“Move declaration X” code action.
A file picker dialog lets you choose an existing destination .go file or
specify a new file path.
Gopls moves the declaration along with its dependent declarations (such as
unexported helpers or methods) while leaving unrelated symbols in place,\n updates references across your workspace, and cleans up imports in both the\n source and destination files.
Interactive "Move declaration" in VS Code
\nIn the example below, we move the type Foo from package from to package\nto. Its method Print and the unexported constant bar, which only Foo\nuses, move along with it, while the unrelated function Baz stays behind:
// from/from.go\npackage from\n\nimport (\n "fmt"\n "strings"\n)\n\nconst bar = "bar"\n\n// Doc comment for Foo\ntype Foo struct{}\n\nfunc (f Foo) Print() {\n fmt.Println(bar)\n}\n\nfunc Baz() string {\n return strings.ToUpper("baz")\n}// from/from.go\npackage from\n\nimport "strings"\n\nfunc Baz() string {\n return strings.ToUpper("baz")\n}\n\n// to/to.go\npackage to\n\nimport "fmt"\n\nconst bar = "bar"\n\n// Doc comment for Foo\ntype Foo struct{}\n\nfunc (f Foo) Print() {\n fmt.Println(bar)\n}Slaying the dragon (gopls v0.24.0)
\nAs a demonstration of multi-step interactive dialogs and a self-contained test\ncase for client editor implementations, gopls v0.24.0 offers a “Slay the\ndragon” code action when you place your cursor on a package-level variable\nnamed dragonSlayer (for example, var dragonSlayer string). Happy hunting!
Interactive refactoring establishes a foundational capability in gopls,\nopening up several exciting directions on our roadmap:
\nChange signature refactoring (#38028): Adding, removing,
or reordering function parameters across a workspace requires input that\ncannot be deduced from syntax alone, such as the new parameter order or the\ndefault argument expression to insert at existing call sites. Interactive\nforms allow gopls to collect these details before rewriting the declaration\nand all call sites.
Interactive conflict resolution: When a code transformation encounters
naming collisions, identifier shadowing, or ambiguous references, gopls can\nask the user for guidance, such as asking for permission to proceed or\noffering to rename conflicting symbols on the fly.
Interactive commands beyond code edits: Because interactivity is modeled
at the LSP command\nlayer, it naturally generalizes to non-edit server\noperations that require user configuration, such as configuring test or\nbenchmark runs with profiling flags (CPU, memory, tracing).
Interactive refactoring is available in gopls v0.24.0\nand vscode-go v0.56.0\n(with proof-of-concept client integrations also explored for\nNeovim and\nEmacs).
We would love to hear your thoughts as we continue\nrefining interactive code actions in gopls:
\nTo read the full technical specification—including the stateless form
protocol design and alternative approaches we explored—or to join the\ndiscussion with the broader LSP community, check out the\nLSP Interactive Code Actions design document\nand the ongoing conversation in microsoft/language-server-protocol#1164.
*(Special thanks to Alan Donovan, Alex Putman, Brian Wilkerson, Danny Tuppeny,\nHana Kim, Madeline Kalil, Peter Weinberger, and Robert Findley for their\ninsights, discussions, feedback, and collaboration on this work.)*
\nHappy refactoring!
","headings":[{"level":1,"text":"Interactive refactoring in gopls","id":"interactive-refactoring-in-gopls"},{"level":3,"text":"What is the Language Server Protocol (LSP)?","id":"what-is-the-language-server-protocol-lsp"},{"level":3,"text":"Multi-step code transformation","id":"multi-step-code-transformation"},{"level":2,"text":"Interactive refactorings in action","id":"interactive-refactorings-in-action"},{"level":2,"text":"What’s on the Horizon","id":"what-s-on-the-horizon"},{"level":2,"text":"Getting Started and Sharing Feedback","id":"getting-started-and-sharing-feedback"}]}}