Connected to SonarQube (and which version): Version 8.9.8 (build 54436)
After connecting VSCode with our SonarQube server, I noticed that the rules sync correctly as far as I can tell, but they don’t always work in the same way.
For example, javascript:S4144 (Functions should not have identical implementations).
I see issues on the SonarQube server, failing my pipeline, but when I look locally, it doesn’t show anything for the same code.
After checking around for a bit, I saw that there is one exception to the rule on SonarQube:
And when I read the same rule’s description in VSCode, there are two:
My case happens to be the same situation as the extra exception, so of course it didn’t show up.
I saw this was a relatively recent addition, probably something for the 9.x versions.
As a test, I recreated the same problem where the exception doesn’t apply, and that showed up fine as expected.
So I assume SonarLint always uses the latest version of a rule?
Our company decided to use the LTS versions, so differences like this will always stick around for a while.
Unfortunately for me, this means that I’m sometimes losing out on the (very appreciated) advantage that SonarLint offers and results in some time lost.
I’m not sure how viable this is, but would it be possible to have SonarLint use the rule versions from the server it’s connecting to? Or maybe add a setting for it? (if it doesn’t exist already, I didn’t find anything)
Hello @Bjornp,
welcome to the Sonar community and many thanks for your feedback!
When you use it in connected mode, SonarLint syncs the Quality Profile configured in SonarQube for your project, so that SonarLint will play the same rules locally.
On the other hand, as you pointed out, the version of the analyzer is not necessarily the same (even more if you are on a SonarQube LTS) as we embed the latest version available of the JavaScript analyzer when we release a new version of SonarLint. A new version of the analyzer can typically bring two kinds of changes to an existing rule:
report more valid issues (i.e. increase true positives)
stop reporting some issues that are false positives
Your case falls in the second category; SonarLint is released quite frequently and I feel it makes sense to always offer the most complete and accurate detection we have available; for example, reporting a False Positive today in SonarLint wouldn’t have much value, because it is not actionable: you don’t need to fix your code, and you cannot mute the issue in SonarLint as we don’t support this yet. In those cases, my suggestion for now is to mark those issues as False Positive in SonarQube (yes, unfortunately only after the Quality Gate has failed).
I understand at the same time that it would be great for SonarLint to show the same issues and measures as SonarQube, so that you can preview the Quality Gate before pushing new code, and this is part of our long-term ambition. For now, there is a range of issues and measures that SonarLint cannot detect yet (e.g. injection vulnerabilities and some other cross-source file issues, code coverage, code duplication).
Being able to preview the Quality Gate in SonarLint is not in our short-term plans yet, but we’ll definitely post any feature ideas in our roadmap page.
I understand the reasoning behind it. I was hoping to be able to avoid the extra work it creates, but it’s not like I’m losing days on it.
Ironically in my situation, what the new version of the rule now considers as an exception, is actually something I see as a valid issue. We’re working with React and have Jest tests. Those tests are all arrow functions, so now duplicate tests are no longer detected and needlessly extend the testing time if overlooked in review. The same thing is the case for duplicate functions in hooks like useEffect.
It’s a relatively minor issue and I honestly wouldn’t know how to solve this with rule changes, so we’ll just have to live with it. Although if I recall correctly, SonarQube v9+ offers some more React specific things, so maybe this is handled slightly differently there?
I guess I’ll find out when a v9 LTS releases
We modified this rule because it was raising too many questionable cases.
I can understand how this doesn’t work well in the example you give.
You are right, we have released new rules for React, and we have more in our short term plans.
I took note of the examples you gave
PS : We do user interviews where developers can talk to Sonar developers and product managers directly. This can be a chance to share your experience. Let me know if you’re interested!
