Ability to limit severity of problems reported by SonarLint in VSCode

SonarLint reports hundreds of problems for the project I’m working on, and so many of them are reported with the Error severity that it’s difficult to find the ones that are actually compile-time errors, even when filtering by problem severity. I’d like to be able to limit the severity of problems reported by the SonarLint plugin to Warning or Info so that I don’t have to manually compile my application to figure out why it isn’t compiling.

I understand that I can change the severity of the issue in SonarLint in my settings.json file, but I would like to not have to update every rule manually, have hundreds of extra lines of settings just for this purpose, or have to update new rules as they are added.

I’d be willing to put in some development work on this if the solution wouldn’t be too complex to implement.

Hi @aweston and welcome to this community forum.

May I ask you a few examples of rules with error severity that are raising a lot of issues on your project? That will help me to better understand the problem and then we can discuss what to do.

Thanks for the feedback anyway!

Here are some for my current project:

Define a constant instead of duplicating this literal “(removed)” 3 times. sonarlint(java:S1192)
Complete cases by adding the missing enum constants or add a default case to this switch. sonarlint(java:S131)
Rename field “logger” to prevent any misunderstanding/clash with field “LOGGER” defined on line 68. sonarlint(java:S1845)
Replace this call to “replaceAll()” by a call to the “replace()” method. sonarlint(java:S5361)

I agree that a lot of these are worth looking at, but at some point they overwhelm you when you’re looking for blockers like compile-time errors. Rather than limiting the error severity in VSCode, it might be more useful to be able to configure how it maps the issue reported by SonarLint to the severity of the problem in VSCode.

Hi @aweston

For now, we’ll start with a quick win. We agree that SonarLint should not use the error severity:

We’ll see later if severity should be made configurable for each rule.

Thanks for the feedback.

I mean, I have no issue with the most egregious issues being categorized as errors, like for a boolean expression that can only evaluate to one value, SQL injection vulnerabilities, etc. I thought you were able to configure rules individually already, which is something I would like to avoid doing since it would be tedious. Plus, since you’re configuring the severity for the rule and not the error in VSCode, I’m not sure how that would play out if you’re connected to a live Sonaraqube instance