Backward Compatible Initialization

[schrieveslaach]

Aas reported in sonarlint.nvim issue #35 (see here) sonarlint-language-server relies on the client to initialize some previously none-required settings. This PR adjusts the language server so that the client can rely on sending minimal init options and avoids NPEs.

[schrieveslaach]

@jblievremont, do you mind to have a look. Sonarlint-ls 4.0 broke sonarlint.nvim.

[sophio-japharidze-sonarsource]

Hey there @schrieveslaach! 👋

Thanks for the PR, we were expecting it! 😄 In fact, we made a conscious decision to have a breaking change and that's why we bumped the major version of the Language Server to 4.0. An equivalent change on the client side should be very straightforward - you can simply pass empty values to the Language Server, and then the actual config will still be pulled from the client later on. Is there a reason you don't want to do this?

All the best,
Sophio

[schrieveslaach]

@sophio-japharidze-sonarsource, we can argue about automaticAnalysis if or not all the clients should send true in the initialize params and I'm open to adapt that. However, I think that a client shouldn't cause the server to crash and push the responsibility of initializing lists/maps to the client. Forcing the client to initialize a list/map reminds me of this SonarQube rule because sonarlint-language-server doesn't follow this rule internally and pushing this responsibility to the outside world.

[sophio-japharidze-sonarsource]

Hi again @schrieveslaach, apologies for the delay. I will test the change you propose soon and merge if all works fine.

On a related note, as I understood your plugin versions are not bound to the SonarLint Language Server versions (i.e. any version of the Language Server is expected to be compatible with any version of the plugin). We maintain the SonarLint Language server to mainly support new features & improvements for our VSCode plugin. So we cannot guarantee that there will be no breaking changes in the future.

I hope this makes sense,
Sophio 🤗

[schrieveslaach]

@sophio-japharidze-sonarsource, thanks for looking into it and considering my PR to be merged.

On a related note, as I understood your plugin versions are not bound to the SonarLint Language Server versions (i.e. any version of the Language Server is expected to be compatible with any version of the plugin). We maintain the SonarLint Language server to mainly support new features & improvements for our VSCode plugin. So we cannot guarantee that there will be no breaking changes in the future.

I hope this makes sense,

I'm not expecting that there won't be any breaking changes and I understand that you can take advantage of releasing those two components in sync because the VS-Code plugin packages sonarlint-language-server in the VSIX file. However, in Neovim land these things are packaged individually (sonarlint.nvim as git repo and the language server as Mason package or distro package). So, there is a necessity to try to keep sonarlint.nvim more compatible with more sonarlint-language-server versions (not just one).

There are cases in which I adopt changes, e.g. when sonarlint/isOpenInEditor changed. However, in this case here, I'm convinced that a client shouldn't break the server, which needs to be fixed upstream.

Additionally, I'm wondering if avoiding breaking changes in sonarlint-language-server reduces friction among the IDE plugin development teams, i.e. sonarlint-intellij, sonarlint-eclipse, VScode, …