I need to analyze some non-standard Javascript (it is Salesforce Aura JS) and every single file gets flagged as totally worthless because of the rule: Non-empty statements should change control flow or have at least one side-effect. One fix for that would be to apply the eslint directive:
// eslint-disable-line no-unused-expressions
which is what we used in our previous non-sonar eslint analysis.
But it doesn’t work in SonarJS. Am I missing some key detail?
hello @wanaselja,
SonarJS will not honor ESLint directives. You can manage which rules are enabled/disabled via Quality profile in SonarQube.
Thanks for the quick reply! Managing which rules are enabled or disabled on a project-wide basis is not enough for my situation. We want to keep the rule generally, but disable the rule for two specific lines per .js file. Unless someone has a better suggestion, my best approach is to abandon the attempt to use SonarJS and use ESLint directly, instead.
We could use SonarJS only if we also installed some kind of pre-processing that deleted the leading ({ and trailing }) before sending the .js to Sonar. Kind of heavyweight and tricky. I like the eslint-disable-line directive a lot more…
Hi,
Just FYI, in SonarQube, analyzers have their own way to exclude issues in a block (see https://docs.sonarqube.org/latest/project-administration/narrowing-the-focus/). So far the same properties are not supported in SonarLint, but that is in our roadmap, at least in connected mode:
https://jira.sonarsource.com/browse/SLCORE-119
Hi @wanaselja,
You can also put “NOSONAR” comment on the line, then all issues on this line will be ignored.
Dear Elena and Julien,
The ‘NOSONAR’ comment is working as I hoped, and only affects the line with the comment. Thanks! FYI: it can be combined harmlessly with the eslint directives:
({ // eslint-disable-line no-unused-expressions NOSONAR
Julien, thank you for the reference to that “narrowing-the-focus” doc. But it doesn’t mention the NOSONAR comment trick. I still wonder where that is documented. And regarding this sentence from “narrowing-the-focus” : Blocks to be ignored are delimited by start and end strings which can be specified by regular expressions (or plain strings).
This is very mysterious to me. Is there supposed to be a paragraph that follows that explains what that means? If that is all that is going to be said about that topic, it seems the doc is assuming a level of expertise I don’t have.
Thanks again for the helpful replies!
In SonarQube we don’t want to expose this feature since we tend to think that adding comments in the code to please a tool is a bad practice. And there is a much cleaner approach that is to mark issues as false positive or won’t fix in the SonarQube UI, and our scanner is smart enough to track issues between consecutive analysis to maintain this status (so issues remains hidden).
It also works fine in SonarLint if you are using connected mode.
//NOSONAR is then only useful when using SonarLint in standalone mode (= without a SonarQube server) since this is the only way to mute a specific issue.
It means you can configure two regexp patterns: one that will match the start of the exclusion zone, one that will match then end of the exclusion zone. All issues inside the zone will be muted.
Any suggestion to improve the wording are welcome 
Thanks Julien!
adding comments in the code to please a tool is a bad practice
That is a great idea, in theory. Yes, it is bad to add comments specific to a particular tool, and the trouble with that gets more obvious when one has to add more comments, one for each tool, as I suggested above. But I think in my one unusual case we have to do it anyway, because the code itself is not right from a stand-alone perspective. I suppose I’d want Javascript to define a tool-agnostic way to say that a line of code isn’t “part of” the code that should be considered stand-alone. But that is very rare requirement.
Aura javascript is really “controller resources”, which are JavaScript objects that contain a map of name-value pairs, where the name is the name of the action handler and the value is a function definition. Apparently something in Aura slurps these things up and makes them run. But the javascript code as saved to the file doesn’t pass linting due to the outer block being an unused expression. I think that makes eslint ignore whatever other linting issues may be within. We ended up pre-processing this kind of javascript. I haven’t figured out a good way to pre-process the javascript so that it will pass linting without using a tool directive, without any unused expression and keep the line numbers the same. For example, prepending "let myUnusedVar = " to the initial “({” isn’t helpful. Maybe a javascript pro could think of something… What we did was to add in the eslint-disable-line comment.
I’m not sure if your “Ignore issues in Blocks” feature would help here, because I don’t know exactly how it works yet.
Any suggestion to improve the wording are welcome
How about providing an example or two?
Thanks again! We are probably just going to use regular eslint for this particular validation job, not the Sonar variation of it. But we’re considering SonarQube for several other things…
