Description
Sometimes we add custom functionalities that are not specified in the standard LSP spec.
For example, for features like vulnerability check and gc details,
we expected the clients to apply heuristics to figure out what features are available.
For example, vscode-go extension used a mix of gopls version (either from gopls version
or
go version -m
command, or from the version encoded in InitializeResult.serverInfo.version
field),
or existence of a certain command in ServerCapabilities.executeCommandProvider.commands
list,
or optimistically assume new functionalities and handle failures. These sort-of worked when custom
commands are involved.
Now we are discussing a prompt ability for go telemetry and adding a setting to control it.
VS Code adds most of the gopls settings in the InitializeParams.initializationOptions
, the very
first message sent to gopls. This can be problematic if the gopls is not able to recognize the setting
yet because the gopls is currently very strict about unrecognized settings.
Some options to consider:
-
Relax gopls's behavior around unknown settings. For diagnostics and visibility, we can still let gopls
add unused settings. -
Require clients to delay sending such configuration until they receive
InitializeResult
that
provides hints about gopls's capabilities. Currently only the version info and commands list are used,
but we can also extend theinitializeResult
to include dynamically settable custom gopls settings list. -
Require clients to figure out the capability through a side channel (e.g. gopls version, gopls api-json, ...).
This is the currently available option and I hope we can do better than that.