When working with different projects/workspaces it does not always make sense to use global settings to turn rules on or off. Also the rules should be committed to a given repository to be shared between developers, which is not possible when only global settings are allowed.
Thank you for your feedback! You’re absolutely right, relying on global settings or local .vscode/settings.json for rule configurations has significant drawbacks, especially in a monorepo where maintaining consistency across the team is vital.
While SonarQube for IDE intentionally limits local rule overrides to prevent configuration drift between developers, you can effectively achieve your goal by using Multi-Root Workspaces in Connected Mode.
By using a Multi-Root Workspace, you can bind each individual project or folder within your monorepo to its own specific project on SonarQube. This allows you to share a dedicated Quality Profile configuration across your team automatically, ensuring everyone is working with the same rule sets without needing to manage them in local settings.
In my opinion SonarQube should not limit local rule overrides, those rules should be limited by what configuration is checked in in version control. If I add .vscode/settings.json to the repository, it should be respected. Also we would like to avoid using connected mode.
Let me follow up with the team on this. Question, why you would like to avoid the connected mode? There are some great benefits beyond getting latest premium analyzers, synchronizing quality profiles, more here.
I am aware of the benefits of connected mode but I am still not interested in them. Also when there are pros on one side there are cons as well and I have no time evaluating that right now.
Besides I tested modifying the package.json of your extension by changing the scope of rules from “application” to “window” and it works just fine as I expect it.