Report count of issues shown for a particular linter type

[inianv]

Your feature request related to a problem? Please describe.

Right now there is no way to simply count the number of issues indicated when a particular linter is enabled. It will be useful to add a command line flag that can indicate the count of issues per linter type

Describe the solution you'd like.

Add a command line flag to summarize the count of each linter config enabled or a specific linter alone

Describe alternatives you've considered.

I could use CLI search tools to get it done. E.g. use a tool like ripgrep to pipe the output

golangci-lint run | rg -w errcheck -c
10

Additional context.

No response

[boring-cyborg]

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

[amarjeetanandsingh]

@ldez
Do you think we should consider implementing this enhancement?

[silverwind]

My preference for a default output would be just a short number summary, like eslint for example:

✖ 39 problems (26 errors, 13 warnings)
  0 errors and 1 warning potentially fixable with the `--fix` option.

Issues-per-linter could be useful too, but I would make that optional to keep output terse.

[4k1k0]

This could be super helpful. I do this with grep and wc but having this already on the tool would be great!

[ldez]

Why do you need this kind of summary?
In which context do to use it?

[4k1k0]

I my case I was fixing an old code base with my team, but there were so many errors that we couldn't implement the fix in a single PR. So I split the task. In order to do this I needed to check how many warnings we had for linter so I can create my user stories.

E.g.

$ golangci-lint run | grep "foo" | wc -l
3
$ golangci-lint run | grep "bar" | wc -l
30
$ golangci-lint run | grep "fizz" | wc -l
20

In this example I would create a user story to fix the bar warnings and another for foo and fizz together. Each task would be implemented in different sprints so we can deliver the fix in different steps in case something failed.

[bombsimon]

You can get reports from a single linter with golangci-lint run --disable-all --enable foo which seems easier than using grep. It doesn't show the count though so wc or similar would still be needed.

I think this issue enables you to get a summary of all linters in a single go without having to invoke golangci-lint multiple times.

[silverwind]

Why do you need this kind of summary? In which context do to use it?

It'd be very useful to track progress while fixing issues. Say for example you have 100 errors, work on some, run the linter again. Now there are 50 errors left, so you know how far you are in one quick glance.

[ldez]

Thank you, now I understand the need.
I tried it with PR #4341 and it makes sense when you use it.

You can get reports from a single linter with golangci-lint run --disable-all --enable foo which seems easier than using grep. It doesn't show the count though so wc or similar would still be needed.

Just a nit-pick, golangci-lint run --disable-all --enable foo is not exactly the same as golangci-lint run | grep "foo" because golangci-lint displays only one report by line, so you can have more reports with --enable than grep. In most use cases, it's the same thing but it can be different.