Best practices for supporting tool-specific configuration file?

[nmoroze]

I'm wondering what the best practice is for how a language server should support an existing language-specific configuration file? For example, say I'm developing a language server for a tool that supports configuration via a myconfig.toml file in the project root. I want the language server to pull configuration from this file if it exists. I see two possible solutions:

1: Have the language server search for and read this file itself.

This option feels relatively straightforward, and doesn't require special client support. However, I'd like to re-run analytics on open files when the configuration is updated. It's less clear to me how to do so cleanly in this case. In addition, it seems more in the spirit of the spec not to assume that the client and server are both running with access to a shared local filesystem, which I believe this method would require (although this seems to be the common case, so perhaps it's an acceptable assumption).

2: Have the client parse the local configuration and pass it to the language server.

This option would use the "proper" LSP configuration mechanisms (i.e. workspace/configuration, workspace/didChangeConfiguration) to configure the server, and leave it up to the client to search for and parse the local project configuration. However, this requires a specialized client implementation per-editor, which seems to defeat the point of the LSP.

Any guidance would be appreciated!

[HighCommander4]

For a language-specific configuration file, I would say option (1) seems more appropriate because it's servers which are language-specific and not clients.

I'd like to re-run analytics on open files when the configuration is updated. It's less clear to me how to do so cleanly in this case.

The LSP has a mechanism for servers to ask clients to watch for filesystem changes to a set of files of the server's choosing, see workspace/didChangeWatchedFiles.

In addition, it seems more in the spirit of the spec not to assume that the client and server are both running with access to a shared local filesystem, which I believe this method would require (although this seems to be the common case, so perhaps it's an acceptable assumption).

I'm less sure about this part, but as one data point, clangd (C/C++ language server) makes this assumption: the contents of the file being edited itself comes from textDocument/didOpen and textDocument/didClose (so the client is reading the file from the filesystem), but the contents of any #include-ed files are read from the filesystem directly by the server.

[dbaeumer]

To my knowledge most servers do (1). If you need something special using getConfiguration is the right way to go. Especially when configurations are stored differently from client to client.