Golangci-lint: Idea: Allow linters to be "warn only"

[Luzifer]

After godox linter was added I'm having an error which is not yet fixable in my code:

main.go:58  godox  main.go:58: Line contains TODO/BUG/FIXME: "TODO(kahlers): Replace with proper limit..."

Seeing this TODO comment in the lint is great because it reminds me I need to do something about that. Sadly the issue was prioritized as "lets do this later" as it is not a business critical issue.

Therefore having an option to set (for example) godox as a warn only linter which reminds me I need to do something but does not fail the linter (if there are only warn only errors left, exit with status 0 instead of 1) would be great.

Sure I also could just add a //nolint:godox but that would also make the output vanish…

[snargleplax]

You could also perform two separate runs with separate configuration files, and treat the results however you want. That would allow you more flexibility, such as having both warning and error settings for a given linter. At the cost, of course, of having two configs to maintain.

[tpounds]

@Luzifer Thanks for the feature request! I agree that this sounds useful and could be exposed in a few ways such as a flag to --show-excluded-errors or as part of a verbose setting --verbose=N. Thoughts?

/cc @jirfag

[jirfag]

I don't believe in warnings as a part of production process (CI, etc). It's a nice thing to see warnings sometimes. But a stable process can be based only on failure if there are any issues. I agree with @snargleplax that you can run golangci-lint just twice: godox should be very fast linter (as I remember it needs only AST) so two runs will be equal by time to one run.

[fho]

We have a similar need.
We have a monorepository with a lot of applications and libraries.
Sometimes it's necessary to deprecate a method but not possible to rework all code at once in the repository not use the deprecated code anymore.

Currently golangci-lint will fail because of the deprecation warnings. To allow deprecations and not fail CI, we currently can only disable the whole linter for the line (// nolint:staticcheck)
This is not a good solution because it also suppresses all other findings from the linter.

It would be great to be able to configure similar to the issues rules, issues that are only warnings and won't result in failed check.

Running golangci-lint twice is not a practical solution:

• it's does not allow to only consider specific issues from a linter as non-critical (e.g. only use of deprecated code issues), it requires to write a script to process the output of golangci-lint and react as needed
• Especial on big codebases it will increase the check time a lot

[snargleplax]

@fho Hushing specific issues within a linter seems like a separable thing, larger than what the OP was after here. My $0.02 would be not to lump it in here, related though it may be.

[Luzifer]

@snargleplax to me it sounds like the exact same use-case. We both want to have certain linter errors handled as "warnings" (displayed but not breaking the build). Sure, my current use-case is not deprecating methods but allowing soft-migrations but in the end that doesn't differ that much.

[jirfag]

1. if you would like to ignore (== don't fail CI build) only some errors from a linter use exclude or exclude-rules. I think you don't really need to display these excluded issues. But if you wish you can run golangci-lint with -v to see them. Or we can add an additional debug flag to only print them.
2. if you see the case when running golangci-lint twice is slow please make an issue for that. It will improve incremental analysis.

[snargleplax]

@Luzifer: It's not identical based on the issue as written. Ignoring entire linters is different (and simpler) than adding the ability to ignore specific issues within a linter.

[stale[bot]]

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.