Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New feature: disable autofix for specific rules in .editorConfig #70428

Open
urmel9 opened this issue Oct 18, 2023 · 3 comments
Open

New feature: disable autofix for specific rules in .editorConfig #70428

urmel9 opened this issue Oct 18, 2023 · 3 comments

Comments

@urmel9
Copy link

urmel9 commented Oct 18, 2023

  • Operating system: Windows
  • IDE: Visual Studio 2022 (64 bit) Version 17.7.5
  • Plugin: SonarAnalyzer.CSharp Version 9.8.0.76515
  • Plugin: StyleCop.Analyzers Version 1.2.0-beta.435

Summary

We want to control which autofixes for specific rules are enabled or not.

Background and Motivation

Beside of the inbuilt-feature Roslyn, we use two Linters: SonarAnalyzers and StyleCop. Here, we activated the function to use the code-cleanup on save that are specified in the .editorConfig. For some rules, we don't need the autofix-feature because it's bugged or just useful. So if we want to turn off the autofix we have to change the severity. Though, some rules are useful to showed but not just the fix.

Proposed Feature

Now we asked SonarLint to add an feature to disable the autofix for specific rules:
New feature: disable autofix for specific rules in .editorConfig](https://community.sonarsource.com/t/new-feature-disable-autofix-for-specific-rules-in-editorconfig/102315/17)
The product manager said we have to ask roslyn because you are maintaining the .editorConfig.

Could you please add a feature that we can disable the autofix-feature for specific rules of Roslyn and third-party analyzers? For example like this:
dotnet_diagnostic.SA1202.autofix = false

Alternative

.eslint is also offering this feature.

@dotnet-issue-labeler dotnet-issue-labeler bot added the untriaged Issues and PRs which have not yet been triaged by a lead label Oct 18, 2023
@genlu genlu added Editor Config and removed untriaged Issues and PRs which have not yet been triaged by a lead labels Oct 30, 2023
@genlu genlu added this to the Backlog milestone Oct 30, 2023
@mavasani
Copy link
Contributor

mavasani commented Nov 2, 2023

Tagging @mikadumont @arkalyanms

This is a reasonable ask - basically provide a way for end users to disable specific quick actions - either from lightbulb menu or some other UX or both. I believe the equivalence key and/or the title + the provider name can be used as the key. I am not sure if editorconfig should be the primary medium for such configurations, as this seems more developer preference, but there might be cases where a repo wants to disable specific kinds of code fixes (as requested here).

If we had a new tool window that showed all available code fixes and refactorings across various scopes (current document/project/solution/all built-in and third party), we can potentially add an Enable/Disable combo box for each quick action. This can be both a discoverability as well as configuration UX for all quick actions. It can be an addition to or an alternative for #70621 towards improving discoverability and configuration of quick actions.

@urmel9
Copy link
Author

urmel9 commented Nov 6, 2023

Hello @mavasani ,
thank you for your answer!

Maybe you could combine the UI-feature with the .editorConfig. When I change the severity via UI, the rule is also added in the .editorConfig. This would be the most functional approach for me! :)

Is it possible to add that functionality earlier than the "new tool window" - for me this are two different features.

Thank you!

@denis-troller
Copy link

To weigh in on this, I think the chosen solution should be repo-first so that the settings can be shared by the team, which seems to me to indicate that EditorConfig could be used, as it is already used by teams to centralize those settings (style-wise).

I thought that was going kind of to be part of #40163, but maybe I read it wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants