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

Allow enabling/disabling new-from-rev per linter #3940

Open
flimzy opened this issue Jul 6, 2023 · 0 comments
Open

Allow enabling/disabling new-from-rev per linter #3940

flimzy opened this issue Jul 6, 2023 · 0 comments
Labels
enhancement New feature or improvement no decision No decision to fix or not

Comments

@flimzy
Copy link

flimzy commented Jul 6, 2023

Your feature request related to a problem? Please describe.

Some linters are only effective when considering code in aggregate, which makes considering only "changed lines" rather ineffective. unused is a prime example. Given the following contrived diff:

 func foo() { /* ... */ }
 
-func bar() {
-   foo()
-}

we would naturally want foo() to now be detected as unused, but with the use of new-from-rev, this is not the case.

Describe the solution you'd like.

I would like the option to disable/ignore the new-from-rev flag for particular linters. unused is the prime use case, but there are likely others where this would be useful as well.

Naturally, this would require that all historical unused code (or other offending lint) be cleaned up, but that's a much smaller chore than cleaning up all lint for the entire project.

Describe alternatives you've considered.

The only alternative I've considered is keeping two .golangci.toml files, with a different subest of linters in each. While this would work reasonably well in a CI pipeline, it does not work nearly as well for local development, particularly when needing to integrate with various editors/IDEs, where custom configuration of the on-save linter can be cumbersome.

This most likely would mean that only one of the linter configs would run locally.

Not a complete deal-breaker, but not ideal.

Additional context.

No response

@flimzy flimzy added the enhancement New feature or improvement label Jul 6, 2023
@ldez ldez added the no decision No decision to fix or not label Mar 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or improvement no decision No decision to fix or not
Projects
None yet
Development

No branches or pull requests

2 participants