Allow custom binaries with custom linters

[firelizzard18]

Your feature request related to a problem? Please describe.

Adding a custom linter is a massive headache.

Describe the solution you'd like.

Provide a mechanism for creating wrapper binaries that register custom linters.

Describe alternatives you've considered.

• Loading custom linters as plugins. This is a massive headache.
• Create a custom wrapper that uses hacks to register a custom linter. I did this, and it works but it's a horrible hack relying on unsafe and it breaks with the latest version.

Additional context.

I already implemented this. If this issue is received positively I will submit a PR.

[ldez]

Hello,

It's fun because I'm currently working on a system to simplify the plugin system 😄

Your implementation doesn't fit with my design expectations.

I will share my POC in a few days.

[firelizzard18]

To be clear the "massive headache" I was referring to is Go's plugin system. I don't see that there's anything you can do to make that much better.

The only thing I care about is that I can install custom linters (probably in a custom binary) without having to use Go's plugin system.

[ldez]

When I said "simplify the plugin system" I didn't talk about Go's plugin system 😉

I'm waiting for the merge of one PR, and once it's done you will see that my POC will, I hope, fit your needs.

You are not alone in complaining about this, the idea of improving the extensibility of golangci-lint is a topic that I have thought about for a long time.

I made important changes recently to the design of some pieces of golangci-lint.
The users will not see them because it's internal things but those changes will improve a lot the maintainability and allow new things.

[ldez]

@firelizzard18 #4437

[firelizzard18]

@ldez That looks good to me, I agree it closes this issue

[ldez]

Can I ask you to give me more information about your usage of custom linters?

example:

• What kind of custom linters are you using?
• Is it related to an internal company usage?
• how do you share them? (if you share them)

[firelizzard18]

It's internal company usage in the sense that they are built specifically for linting rules I wanted to apply to our codebase. But it's 100% open source so anyone who wanted to could copy them, I just don't advertise/publish them, mostly because they're just good enough for my purposes and not polished.

rangevarref detects code that captures a reference to a range variable (the bug that lead to the loopvar changes). I discovered exportloopref after the fact, which may serve the same purpose, but I've never bothered to check since my version works well enough.

The other two, nodebug and noprint, could probably be replaced by forbidigo but again my version works well enough. nodebug detects var debugFoo = true to prevent debug-enable flags from being merged. noprint forbids print statements in the majority of the code base since we use logging libraries instead for output (in most places).