SonarLint VSCode settings spread over Workspace / User / Remote

SonarQube for IDE VS Code
1
  • Operating system: Ubuntu 20.04
  • IDE name and flavor/env: VSCode v1.67.0
  • SonarLint plugin version: v3.4.1
  • Is connected mode used: Yes
    • Connected to SonarCloud or SonarQube (and which version): SonarQube Version 8.9.7 (build 52159)

We are evaluating SonarLint in our team and appreciate the tool a lot. But currently we have doubts if we well understand the way how to configure especially the connected mode for VSCode.
It would be quite desirable to configure the project (workspace) related settings all together in the “Workspace’s” settings.json:

We didn’t manage to set the SQ server parameters in the “Workspace” settings.json file, the server can only be found if the parameters are set in the local “User” settings.json file. Then it’s not possible to store an “out of the box” working environment in a project repository, developers who only work occasionally on the project always have to manually edit their local VSCode “User” settings.json. At the moment it’s even worse as in case of working remotely on VSCode the path to the compile_commands.json has to be specified in the “Remote” settings.json file, otherwise it doesn’t work. In sum four config parameters are spread over three config files which looks strange.

Thank you for support,
Hubert

2

Hello, thanks for your feedback.

We are well aware of usability issues with the connected mode setup in VSCode and this is something that we definitely want to tackle in the upcoming weeks/months.

This being said, the split between folder, machine and user properties is actually on purpose:

  • the folder settings are specific to each project/folder, to tell SonarLint which remote project should be synchronized with a given folder and allow per-folder binding
  • the machine settings (like the path to compile_commands.json, or the path to Node) are specific to one machine: even for a given user, there is no guarantee that it should be the same across all their development environments
  • the user settings (like the server URL and token) are meant to be private to a given user - the token is a credential, definitely not meant to be shared by several users, though OK to share between a single user’s projects/folders

I believe that sharing some/most of the configuration properties in a project’s SCM repository is a use case we would like to support, and I am pretty sure this should not include the token. Actually, it should not even appear in clear text in the settings; we have plans to use VSCode’s (recently introduced) secrets API instead, and this will require a bit of work on the UI side.

3

Thanks a lot for the quick clarification! Now that the background is clear we can better understand.