Protocol for reporting configuration structure (and current configuration)?

[idanarye]

Language servers can have their own settings, can be pushed from the client to the server using workspace/didChangeConfiguration or requested by the server using workspace/configuration. Each language server can have its own configuration fields, and they tend to configure the structure of these settings to the companion VSCode plugin - more specifically, the contributes.configuration field of the package.json file. This allows (I assume) VSCode to render a nice menu with all the language server's specific settings.

Since LSP is supposed to be tool agnostic, it would be nice if the client could get from the language server the specifications for the configuration it supports. That way every client - not just VSCode - could render a UI for the user to configure the language server. Or, at the very least least, format a scaffold for the configuration for the user to manually edit.

Additionally, since configuration settings can come from other sources (e.g. - project configuration files), I think the client should be able to get from the server the current values of the configuration, to display them in the new settings UIs and to avoid overwriting them with the defaults it gets from the language server.

[felixfbecker]

The problem I see is that you don't want to spawn all language servers just to be able to edit validate the configuration file. The schema should rather be known statically, like VS Code extension's package.json contributes.configuration field. Maybe we could just establish a convention of all language servers shipping a JSON schema file for the configuration they expect in workspace/didChangeConfiguration?

[dbaeumer]

In general the push configuration model (based on workspace/didChangeConfiguration) is discouraged in favor of the pull model. The pull model has the advantage that the server can define its settings structure and that clients need to map this to their setting store. I do see the hole of needing to define the structure of these settings. So besides a server documenting the settings in its readme it makes perfect sense that a server provides a corresponding json schema file as well. May be it makes sense to server it dynamically as well using a request or a property in the server capabilities.

[vscodebot]

We closed this issue because we don't plan to address it in the foreseeable future. You can find more detailed information about our decision-making process here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

[matklad]

I am somewhat surprised that this is closed as out of scope.

• "how do I configure server X in editor Y" is a very frequent question which new users face
• lack of config validation (and mismatches between client-side validation in VS Code and serve-side config semantics) are a common problem for everyone.

rust-analyzer ended up adding some build-time code-generation to:

• print the schema on rust-analyzer --print-config-schema JSON command
• generate docs
• sync with package.json

It'd be sweat if I could do just the first point (or analogue), and be sure that whichever editor is the client, it'll do a decent job explaining to the user how to actually configure the thing.

[dbaeumer]

But how should a client do that magically. IMO the JSON structure somehow matches to the settings store in the editor than this is easy. If no, client code is needed to adopt.

[matklad]

This definitely should be doable in principle -- if the client is able to adapt settings store to the shape of JSON expected by the server, it should also be able to apply similar automated transformation to the schema as well.

I am not sure what's the best way to achieve that -- what rust-analyzer does is simply the closest thing to existing VS Code schema (which uses dotted.keys rather than nested structures). But this might be good enough actually? Looks like the state of the art for on-vs code extension is to parse vs code package.json's anyways.

[puremourning]

I dunno if this is flogging a dead horse or not, but the lack of definition of these settings is really quite a pain point for us as a client author and for our users.

In practice, there's probably only 1 client for which 'client' glue code exists for most servers. For many other clients, users are expected to configure whatever the server requires by reading the server's documentation (should it exist), or guessing. The concept of "sections" seems kind of bespoke, and there are nonzero servers which request sections like vscode.something.something, which of course don't exist in any user-specified configuration for $server.

Having some common, or let's say, recommended way to describe the settings would be a good thing. DAP has the same problem for launch arguments. Right now, it's pot luck whether there's any documentation other than the server code and/or the server's vscode plugin code.

I could be misunderstanding, but I'm not sure that the "Pull" model really helps, as users still have no way to know where to put the configuration or what to write there.

What ends up happening is that we as a generic client have to end up documenting how to configure X,Y,Z server and field questions from users who (rightly) don't have any idea what a language server is or which one they are using. They are just using "My Client" for "Some Language".

I admit that from the LSP perspective, it's not completely obvious what that "recommendation" should be, or if it should be a formalised schema represented in the protocol, but we find that if we can say "Yes, but the LSP specification states that " enen if it's a recommendation, that goes some way to getting conformity.

I hope that's useful in some way in the thought process.

[dbaeumer]

I see the points but IMO the best way to move this forward is to write a recommendation how a server should be documented. One item in that documentation should be the configuration structure it requests. The structure can be documented using JSON schema or TS interfaces (which can easily to converted to JSON schema using typescript-json-schema. Other things are the command line arguments to start the server.

Even the servers I develop don't read the VS Code setting store 1:1. I always have code that maps a simplified flat server configuration to a more complex client settings store configuration. Even if the server would return the configuration it uses as a JSON schema I couldn't write any code that automatically maps that to the VS Code settings store. Here is an example for ESLint https://github.com/microsoft/vscode-eslint/blob/master/client/src/extension.ts#L1373

What the ESLint server would need to document is this:

interface CommonSettings {
	validate: Validate;
	packageManager: 'npm' | 'yarn' | 'pnpm';
	codeAction: CodeActionSettings;
	codeActionOnSave: CodeActionsOnSaveSettings;
	format: boolean;
	quiet: boolean;
	onIgnoredFiles: ESLintSeverity;
	options: ESLintOptions | undefined;
	run: RunValues;
	nodePath: string | null;
	workspaceFolder: WorkspaceFolder | undefined;
}

interface ConfigurationSettings extends CommonSettings {
	workingDirectory: ModeItem | DirectoryItem | undefined;
}

interface TextDocumentSettings extends CommonSettings {
	silent: boolean;
	workingDirectory: DirectoryItem | undefined;
}

[matklad]

Thanks for this example, I misunderstood what you meant by mapping between editor's config store and server config. I agree that having a scheme doesn't help in this case.

I wonder if any clients beyond VS Code actually do this though -- as far as I know, they just forward whatever is there in the appropriate settings file in a generic, server-agnostic way.