Running SonarLint language server from shell?

Hello everyone,

I want to get SonarLint working in Neovim based on the LSP server. Since the LSP server is already used by SonarLint for VS Code and Neovim understands LSP as well, it means I should be able to achieve my goal simply by connecting to the LSP server.

In order to get an understanding for how to use the LSP server I wanted to first run it from the shell and poke around a bit. So I cloned the Git repo, ran mvn verify and it built without issues. Then I ran java -jar target/sonarlint-language-server-1.2-SNAPSHOT.jar and I got a message that I need to specify a port. No problem, just pass some port like 8080, right?

Well, that’s where my confusion begins. From looking at the error message and the Java source code it looks like the application wants to open a client port to an existing server. But should the application not be the server and my editor the client which connects to it? It seems I’m having something backwards here. I can run other language servers like pyls, clangd or eclipse.jdt.ls from the shell; they are not useful that way, but they work.

Would someone please be kind enough to clear up my confusion? It seems I need to launch some other application as a server first, and then pass the port to this application, but then how does it communicate with the editor?

2 Likes

Hi,

The LSP can rely on different “transport”: stdout/stdin streams, network sockets, … Since the communication is bi-directional, it doesn’t really matter who is creating the socket. In VSCode workflow, the client (= the VSCode extension) is creating a socket, then starting the SonarLint LS like you did, passing the socket port as argument. The server will then connect to this socket, and the communication will start between client and server. I think the term “server” might be confusing here. It means “serving a feature”.

As a side note, I would be interested to know what language(s) you are working with and you think SonarLint could be interesting for in Neovim.

In VSCode workflow, the client (= the VSCode extension) is creating a socket, then starting the SonarLint LS like you did, passing the socket port as argument. The server will then connect to this socket, and the communication will start between client and server.

I see, that complicates things somewhat, but it’s still possible. Is it not possible to use stdin/stdout?

As a side note, I would be interested to know what language(s) you are working with

Do you mean which language I am working with, or which language Neovim plugins are developed in? I am using Java at my dayjob and I use the eclipse.jdt.ls language server for getting all the IDE-like features. It’s a bit like having a headless IDE where I bring my own interface, I really like it. As for developing Neovim plugins, the best choice is Vim script or Lua, both are built-in. It is also possible to write plugins in any other language, provided you have an API client for it. So you can write proper Neovim plugins using just Java if you want to.

and you think SonarLint could be interesting for in Neovim.

Definitely. Neovim (and Vim) is not an IDE, it’s just a plain text editor, but one that is programmable. I can hook up other programs to it, and I don’t see why SonarLint should not be among them. I could gush about it all day, but I think that would be off-topic :wink:

It is possible (the lsp4j library we are using is not enforcing any “transport”). But currently the SonarLint LS only works with sockets.

Thanks for the details about Neovim and languages. I don’t think it will be in our roadmap at short term, but that’s always interesting to ear about new use cases.

I wasn’t really expecting official Neovim support (although that would have been awesome), but we should be able to meet somewhere halfway. LSP is not just for VS Code, and you have already implemented all the functionality.

The only thing that’s missing is a more convenient way to connect to the the language server. If the server provided alternative connections it would benefit many more text editors which also support LSP already (one could e.g. pass additional command-line options to choose the type of connection). Even if those other editors are not officially supported, just the fact that people can hook up their editor of choice on their own with minimal effort would bring in additional value to SonarLint. I don’t know if SonarLint is open to contributions from the outside, but if it is I’m sure we can find a solution that introduces only minimal changes to the codebase.

Funnily enough, I was searching for the same thing today. So I want to give a +1 and say that it would be really helpful if we could get some guidance on how to leverage the SonarLint functionality via LSP (similar to how it’s being done for VSCode).
For context, I’m using Vim to write Java and it would be nice to hook into our SonarQube server to use the linting functionality.

LSP is not just for VS Code

Yeah, that’s the theory. When we were maintaining SonarLint for Atom, we realized the spec is not always clear enough to ensure consistent behavior, and we sometimes had to implement special case for each IDE.

I don’t know if SonarLint is open to contributions from the outside

Yes and no. We are open to contributions if they fix existing issues. When it come to new features, we are extra careful, because more than often, people are eager to put more stuff in our products, but not to maintain them on the long run :slight_smile: So a contribution has to be consistent with our vision and will to maintain it on the long run.

Regarding enabling stdin/stdout communication, this is something I already had in mind, so we could definitely accept a contribution. But last time I gave a look, it was not that obvious. I know the Redhat LS for Java is able to switch to different ways of communication, so that might be a good source of inspiration.

YouCompleteMe for vim also provides LSP support. I tried to connect SonaLint language server with socat. E.g. with something like socat TCP4:localhost:10080 - and then connecting the SonarLint language server to it. Unfortunately that also didn’t work for some reason. Didn’t look closer into that.

Anyways also a +1 for vim support from me :wink: