lsp: Neovim client not responding properly to configuration requests

[giluis]

Hello,
I love Deno. While setting up denols for Neovim, the language server behaves in a strange way. It runs only once. And then it stops. Meaning it shows diagnostics to the initial state of the file, but does not react to further changes, until I close the file and reopen.

Error converting specifier settings (file:///<path_to_file>): invalid type: null, expected struct SpecifierSettings

Is anyone familiar with this issue?
How can I solve it? I can provide more details if necessary.

[kitsonk]

The client is returning an unexpected response to a configuration request.

Specifically the Deno language server is sending a workspace/configuration request to the client with a scope of the file that appears to be open to determine the configuration, and instead of providing the information, it is returning null.

I suspect it is an issue with the client.

[giluis]

Thanks. I will open an isuse in Neovim Lsp client.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[valpackett]

It is a bit strange though that deno lsp requires configuration to be present. For the vast majority of LSP servers, having configuration is not mandatory.

[kitsonk]

The Deno language server operates in an environment where other language servers tend to operate and needs to determine if it should be enabled for a given project. Just because you use the Deno language server does it mean you want every JavaScript and TypeScript file in your editor you want to be handled by Deno.

@unrelentingtech what problem is this situation causing you?

[valpackett]

Not all editors / LSP clients support per-project configuration, not all even support any configuration. So it becomes non-trivial to make it work with some editors.

For example I've had to figure out a magic incantation to add to Helix's languages.toml:

config = { deno = { enable = true, lint = true } }

by looking at debug messages to see what the server doesn't like.

[kitsonk]

Well configuration is part of the language server protocol, and enabling granular configuration on per resource/per project was an important feature requested by users. That being said, we don't really respect the client capability around workspace folders, and if they don't support workspace folders, we still query on a per resource basis.

The initial implementation of workspace folders was rather naïve on my part and in doing the "enableFolders" feature, I better understood ways of handling it, not needing to query on every file. I can see the sense in re-working that whole feature, as I have wanted to for a while. The issue with other editors clarifies that need.