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

Let me selectively disable linters from CLI which are enabled in the config #1272

Closed
julienschmidt opened this issue Jul 26, 2020 · 7 comments
Labels
enhancement New feature or improvement

Comments

@julienschmidt
Copy link

julienschmidt commented Jul 26, 2020

Is your feature request related to a problem? Please describe.
I use golangci-lint with a global .golangci-lint.yaml config in my daily dev flow. I sometimes use it to check code that I don't own (so adding a local config is not really a solution).

Sometimes a linter from my default config causes problems or gives too many results, thus I'd like to disable it.

Describe the solution you'd like

I'd like a way to disable a (set of) specific linter(s) from the CLI, i.e. the -D flag should have precedence over the enable list in my global config. Currently this is not allowed:

Running error: linter "superduperlinter" can't be disabled and enabled at one moment

@julienschmidt julienschmidt added the enhancement New feature or improvement label Jul 26, 2020
@boring-cyborg
Copy link

boring-cyborg bot commented Jul 26, 2020

Hey, thank you for opening your first Issue ! 🙂 If you would like to contribute we have a guide for contributors.

@sayboras
Copy link
Member

Not sure if you tried golangci-lint run --disable-all --enable <list of linters>. This one might not be completely ideal in your use case, but it could be alternative option.

Personally, I like to keep it simple like below, which one option will supercede another option field by field, but not all inter dependencies among them. AFAIK, a lot of OSS projects are moving in declarative configuration way, which is taking config file as source of true.

The config file has lower priority than command-line options. If the same bool/string/int option is provided on the command-line and in the config file, the option from command-line will be used. Slice options (e.g. list of enabled/disabled linters) are combined from the command-line and config file.

@stale
Copy link

stale bot commented Jul 29, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale No recent correspondence or work activity label Jul 29, 2021
@stale stale bot closed this as completed Aug 29, 2021
@Frederick888
Copy link

As much as I understand the motivation behind @sayboras's comment, still it'll make my life a lot easier if --enable/--disable can be applied on top of configuration file.

I'm using gopls along with ale to run golangci-lint, and in our configuration file we've enabled typecheck. While this makes perfect sense when running it from command line locally or in CI, in Vim whatever typecheck reports just clashes with gopls diagnostics.

So now it seems that I have to write a Vimscript function to locate the configuration file, parse it, ignore typecheck and finally build arguments --disable-all --enable xxx,yyy. It'll be great if I can simply let g:ale_go_golangci_lint_options = '-D typecheck' instead.

@bombsimon
Copy link
Member

You can't ignore typecheck since it's not a real linter, it's golangci-lint's way of reporting compilation errors. When the code doesn't compile no reports are to be seen as reliable since they're not on passing codes. So to clarify, golangci-lint run --disable-all --enable gofmt would still report errors from typecheck if the code doesn't compile.

@Frederick888
Copy link

Frederick888 commented Nov 8, 2021

@bombsimon You were right... I just wrote the vimscript to parse golangci-lint linters output and constructed --no-config --disable-all -E aaa,bbb,ccc and it still reported typecheck errors.

Reason though, was not that my code didn't compile, but was that ALE runs golangci-lint on individual files (for better performance and an easier-to-parse output I guess). So I ended up with tons of undeclared name: SomeType errors from same-package types. I wonder if there is a good way to work around this issue?

And by the way without --no-config, --disable-all -E aaa,bbb,ccc alone didn't actually 'supersede' enabled linters from config file but merged them (v1.43.0). So now having to use --no-config is also a little problematic as my linters-settings are ignored.

Edit: I enabled let g:ale_go_golangci_lint_package = 1 so at least it doesn't report false positives.

@evanmoses-okta
Copy link

I would like this option as well. CLI flags should have precedence over config files, so I can have a config file but occasionally invoke the linter with a different set of checkers enabled. There is a clear precedence. My particular use-case is that I'd like to disable a slow linter on a single OS in a github action that runs on multiple OSes without creating a different config file for each os. So they use the same config, but on the github action for windows I would run

args: --timeout 10m -D goimports,

Where the -D list comes from other configuration in the Action.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or improvement
Projects
None yet
Development

No branches or pull requests

6 participants