Automatic discovery of Language Servers

[kryptan]

Currently each IDE needs to be configured for each Language Server implementation. It would be nice if there was a way for IDEs to automatically detect installed servers.

This is possible for Jupyter kernels, each Jupyter kernel installs its config in ~/.jupyter and VSCode can automatically detect all installed Jupyter kernels, no need for any additional configuration or extensions.

Similar setup should work for LSP. There can be some standard folder like ~/.lsp. Each installed Language Server would store its config there. This config will specify command to run the server and will contain a list of supported file patters (e.g. file extensions and special files like package.json or Cargo.toml to look for). If IDE detects that there is a Language Server suitable for the current file/directory it could ask user to run it.

[mickaelistria]

I find this idea interesting and it echoes a (5-years old already?) idea of a language server registry that would also include the provisioning steps. But I have some doubts about it:
Usually, there are small details that make that running the LS is more than just running a command: the client sometimes have to check for pre-requisites, pass some specific system properties, decide whether std or socket fits best, decide whether to store some extra logs, decide of a particular runtime to use, sometimes pass extra configuration settings upon startup... All that is hard to capture in such a list of installed LS as the final set of operation to properly run the LS is more dynamically computed.

[dbaeumer]

From all my experiences I came to the same conclusion than @mickaelistria. Usually this work in a starter case but as soon as language servers need more configuration being able to customize things is a big help. What I definitely want to avoid is to maintain a configuration language to be able to express this.

[mfussenegger]

Going by the servers supported in https://github.com/neovim/nvim-lspconfig/ I've the impression that the vast majority is really only cmd, filetypes and a way to detect a project root/workspace directory or signal if the server supports "single-file mode" (no workspace folder).

The project root detection is because in editors like nvim you don't start by creating a workspace folder, but you edit files directly (nvim path/to/file) and based on that file path you need to determine what the workspace folder could be. Usually that's stuff like .git, pyproject.toml, Cargo.toml.

Clients could still provide configuration options on top.

[angelozerr]

Hi all,

@mickaelistria suggested me to speak about https://github.com/redhat-developer/lsp4ij which is a free LSP/DAP support for IntellIj. You can register any LSP/DAP server programmaticly with an extension point (it requires to develop an IntelliJ plugin) or with declarative mean. To help user to configure language server, LSP4IJ uses templates for LSP and DAP, see https://github.com/redhat-developer/lsp4ij/tree/main/src/main/resources/templates

Here a demo with JDT LS based on those JSON files (only) https://github.com/redhat-developer/lsp4ij/tree/main/src/main/resources/templates/lsp/jdtls

As you can see, user need just to select the language server and everything is working:

• it create a language server with a name, command (which is invalid before the installation) and file mappings (documentSelector). with https://github.com/redhat-developer/lsp4ij/blob/main/src/main/resources/templates/lsp/jdtls/template.json You can even fill the LSP configuration (based on a JSON Schema if you wish) and initializationOptions.
• when a Java file is opened, the language server uses the installer JSON https://github.com/redhat-developer/lsp4ij/blob/main/src/main/resources/templates/lsp/jdtls/installer.json:
  • it tries to execute the current command (declared in https://github.com/redhat-developer/lsp4ij/blob/335daf80eacc91f1b12730b6fd963645bb8f2340/src/main/resources/templates/lsp/jdtls/installer.json#L6) and if it fails, it switch to run install section https://github.com/redhat-developer/lsp4ij/blob/335daf80eacc91f1b12730b6fd963645bb8f2340/src/main/resources/templates/lsp/jdtls/installer.json#L12
  • it download the JDT LS with this url https://github.com/redhat-developer/lsp4ij/blob/335daf80eacc91f1b12730b6fd963645bb8f2340/src/main/resources/templates/lsp/jdtls/installer.json#L14
  • extract the compressed file in a given folder https://github.com/redhat-developer/lsp4ij/blob/335daf80eacc91f1b12730b6fd963645bb8f2340/src/main/resources/templates/lsp/jdtls/installer.json#L16 ($USER_HOME$ is a special IntelliJ variable)
  • update the right of the bin file https://github.com/redhat-developer/lsp4ij/blob/335daf80eacc91f1b12730b6fd963645bb8f2340/src/main/resources/templates/lsp/jdtls/installer.json#L20 according the OS
  • update the start command to use the extracted JDT LS folder https://github.com/redhat-developer/lsp4ij/blob/335daf80eacc91f1b12730b6fd963645bb8f2340/src/main/resources/templates/lsp/jdtls/installer.json#L28

This JDT LS is very simple because for instance URL is hard coded (it gives the last release of JDT LS), but you can have several URLs according OS, like rust, see https://github.com/redhat-developer/lsp4ij/blob/main/src/main/resources/templates/lsp/rust-analyzer/installer.json

It is working also with DAP server, see JSON files decriptor for vscode-js-debug in https://github.com/redhat-developer/lsp4ij/blob/main/src/main/resources/templates/dap/vscode-js-debug/template.json which declare the DAP server installation is done with https://github.com/redhat-developer/lsp4ij/blob/main/src/main/resources/templates/dap/vscode-js-debug/installer.json which download the zip, extract it and update the DAP server command

It would be fantastic if we could have a sec about declaring a language server (id, name, command according to the OS, file mappings (documentSelector) and installer. We could host those descritor in a web server that any LSP/DAP client could consume it to install any language server.

The only problem that I have not fixed correctly is the runtime. For instance some language servers requires, node, go runtime. I need to manage an error message (with a link to install runtime) to notify that user need to install a given runtime and restart the computer to update the env PATH.

Hope you will like this idea.

I have started a documentation at https://github.com/redhat-developer/lsp4ij/blob/main/docs/UserDefinedLanguageServerTemplate.md
*