As I learned in this post LTS version of SonarQube gets no updates of language plugins. SonarLint in general is (like SonarQube) constantly improved. How can I find out, which version of each SonarLint plugin fits best to my LTS version? So that the installed SonarLint version doesn’t have different rules bundled than the SonarQube server we’re running.
Hi @Fischermaen ,
This is a very interesting question. The short answer is that you should always aim at using the latest version of SonarLint, this is what we think will bring the best value for your developers.
Long answer:
SonarLint uses its own embedded versions of analyzers when used alone. We release frequently to always benefit from latest improvements.
When connected to SonarQube or SonarCloud… it depends. Some flavors of SonarLint will download the analyzers that are on the server, while some other flavors will continue to use the embedded one. In both cases, rules activation and parameters will come from the server.
If you follow our advice to use a recent version of SonarLint, SonarLint will either run the exact same analyzers versions as SonarQube, or more recent versions. More recent versions of analyzers may have some fixes/improvements to existing rules, but we believe this is only for the best:
- less false positive: some (false) issues will not be detected by SonarLint, but will be raised by SonarQube → users can mark the issue as false positive in Sonarqube. I don’t think this is a big loss to not see those issues in the IDE.
- less false negative: some (true) issues will be detected by SonarLint and not by SonarQube. Developers are free to fix them in their IDE or not, but this can only a plus for the codebase quality.
1 Like
@Julien_HENRY thank you for your quick reply.
You’re right, it’s no problem to not see the issues in the IDE, but it is additional (useless) work to close those issues in the web interface. This will lead to developer frustration especially when there are a lot of false positives of this kind.
You’re right, this is no issue.
Hi @Julien_HENRY,
may i humbly ask you to be more elaborate in your explanation?
So, while trying to parse/interpret your answer i am now having the following assumption:
By “flavors” Julien is talking about the Plugins for the different IDEs … and probably - i think - there are two categories (the ones who dl’s the analyzers from server vs. the ones who use the embedded)
Would it be possible for you to please list them as either “downloading” or “embedding”?
TYVM in Advance!
cheers
Daniel
P.S.: If i might have gotten the meaning of “flavors” wrong i would very much like to ask for an explanation, too, concerning the flavors of SonarLint you ment 
Hi @daniel
Sure 
Exact. We have 4 “flavors”: SL for IntelliJ Platform, SL for Eclipse, SL for Visual Studio and SL for VSCode.
First a clarification: when we say that SonarLint downloads analyzers from the server, it doesn’t mean it will download all analyzers (in particular don’t expect SonarLint to run third party analyzers). Each SonarLint flavor has its own list of supported languages. So the question here is: for a SonarLint flavor supporting language X, does it uses the X analyzers embedded, or take the version from the server?
This is not a boolean answer and this is not a commitment that it will still be valid in the future. Anyway, here is the current situation:
- SonarLint for IntelliJ: downloading analyzers from the server, except for C/C++ and C# analyzers that are always the embedded ones
- SonarLint for Eclipse: downloading analyzers from the server
- SonarLint for VSCode: downloading analyzers from the server (but when C/C++/C# support will be added, it will certainly rely on embedded analyzers)
- SonarLint for VS: use embedded analyzers
In the past, we were really aiming at downloading analyzers. SonarLint for VS was an exception for technical reasons. Recently, for various reasons, we are slowly moving to the other direction (=only use embedded analyzers). But it has its own challenges as well, so we might stay in this hybrid approach for quite a while.
As a reminder, the good practice is to always try to use the more recent version of SonarLint, even with SonarQube LTS.
2 Likes
@Julien_HENRY: Thank you very much for the insights of SonarLint “flavors”
IMHO there will be a decrease of acceptance when SonarLint reports no errors and the subsequenting analysis on the SonarQube server will break the quality gate due to different version of scannners! And this will happen to all users of LTS version!
So, still looking for a chance to identify the SonarLint version which will fit bestto installed LTS version of SonarQube…
We think it is a dead end to put a strong constraint on the fact that SonarLint and SonarQube raise the same issues. Even with the same analyzers. There are different things you can do when you run in an IDE, on a dev machine, (almost) on the fly, compared to what you can do on a CI server.
Latest + use connected mode
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.