Add setting to disable all rules for a language

[duncanp-sonar]

Description

At present the only way to completely disable analysis for a language is to individually disable all of the rules for that language, either in the settings file (standalone mode) or in the Quality Profile (connected mode). This isn't a practical solution, given that each language has hundreds of rules.

It should be possible to disable all of the rules for a specific language via a single setting in the user settings file.

Out of scope

The following features are out of scope for now:

• UI to disable/enable languages

Should the setting apply in Connected mode, or only in Standalone mode?

At present, the rule configurations in the user settings file are ignored in Connected mode, the thinking being that the Quality Profile settings should take precedence in that case.

However, the individual developer should be in control of the development experience in their IDE, so they should be able to completely disable analysis for a language if they wish.

Implementation

TODO

• [x] add appropriate settings to the settings.json config file
• [x] update the JavaScript rules provider to respect the new setting
• [ ] update the CFamily rules provider to respect the new setting
• [ ] add telemetry to record disabled languages
• [ ] update documentation

File format

The json format of the new setting will be as follows:

{
  "sonarlint.general": {
    "disabledLanguages": ["cpp", "c", "js"]
  },

  "sonarlint.rules": {
...
  }
}

The values stored will be the Sonar language keys i.e. cpp, c, js, ts etc.

[Eli-Black-Work]

@duncanp-sonar Has any of this feature already been shipped as part of the SonarLint VS extension? I'm looking to disable SonarLint for JS and TS files while in non-connected mode.

e.g.

  "sonarlint.general": {
    "disabledLanguages": ["js", "ts"]
  },

Thanks! 🙂

[duncanp-sonar]

Hi @Bosch-Eli-Black. No, it's not shipped. We ran out of time to implement it in the sprint and it was cut. It's still on the backlog, but not currently prioritised.

cc @marco-comi-sonarsource for info.

[Eli-Black-Work]

@duncanp-sonar Okay, thanks 🙂

I don't think this is a priority for us, either. I was hoping to be able to temporarily disable JS warnings while I tested out the SonarLint extension, but long-term, we probably want to use connected mode and/or configure which JS errors we want to see, anyway.

[duncanp-sonar]

@Bosch-Eli-Black FYI JS/TS rule configuration is currently only supported in standalone mode. Support for connected mode is covered in #770.

[Eli-Black-Work]

@duncanp-sonar Yes, thanks; I was just looking to use this feature as a quick hack before we configured out JS projects to be in connected mode. Once we're in connected mode, I don't think we'll need it 🙂

[rjgotten]

@duncanp-sonar

I would really, really, really, REALLY appreciate having this feature delivered in light of Microsoft having utterly stuffed up something wrt TypeScript typings and their general support for Intellisense - to the point where they now triggers an ocean of warnings on typings in /node_modules folders that are part of regular old ASP.NET web projects; not JS or TS projects, and are in fact meant to be consumed by totally different tooling - i.e. Webpack in my case.

Problems on that end can be temporarily worked around by creating a dummy jsconfig.json or tsconfig.json file and just instructing it to exclude everything which gets Visual Studio's builds; real-time intellisense; and code analysis features to shut their pot hole about these non-problems.

But when you open a JS or TS file for a quick edit, it's SonarLint which will still kick in analysis and that triggers the built-in TypeScript Intellisense to start digging and: boom! -- you're right back to square one with a 2000+ error log being puked out in your face.

[duncanp-sonar]

@rjgotten

But when you open a JS or TS file for a quick edit, it's SonarLint which will still kick in analysis and that triggers the built-in TypeScript Intellisense

The SonarLint analysis of JS/TS is run in an external process; it is not connected with TypeScript IntelliSense in any way. Doesn't the TypeScript IntelliSense kick in whenever the file is opened anyway, regardless of whether SonarLint is installed or not?

[rjgotten]

In this case; no. It didn't. Or atleast: it didn't exhibit the broken behavior in question in this case. (Mind you; workarounds to get it to side-skirt the broken behavior were really hacky either way.)

If SonarLint runs isolated, then I'm wondering if this somehow has something to do with some of the internals of Visual Studio and how it decides when to kick off analysis. Like; if however SonarLint hooks in also causes other analyzers to be considered, and somehow it all still has a bug on Microsoft's side or something where TS Intellisense pops back in with its currently buggy behavior.

Regardless; I've learned since that apparantly there is already a fix forthcoming on the MS side in VS 2022 v17.2 which is currently in preview. It's a pain having to reconfigure the errors panel in VS to filter out the TS related errors every time, but I guess that's still doable until their fix lands in stable.

Thanks anyway for replying. :+1:

[mandric]

+1 for allowing the plugin to be disabled from .vscode/settings.json in the project itself, otherwise I need to ditch the plugin completely and go back to sonarqube cli invocation. Seems like a core feature of any vscode extension that is developer friendly.