Additional Plugin Architecture

[idcmp]

Your feature request related to a problem? Please describe.

Building a private plugin is a painfully brittle experience, between needing to vendor specific versions of everything, and working around known issues with xxhash (from the prometheus linter) not being dynamically linkable, to having the wrong version of Go, to ultimately still not working - it's almost not worth it.

Describe the solution you'd like.

I'd like a solution that didn't use Go's plugin system; even if it had a bit of a performance hit, thus I could keep some local linters that are very specific to project.

Describe alternatives you've considered.

It'd be interesting to have an "external" linter that used https://github.com/hashicorp/go-plugin to talk to linters.

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.

[yuxincs]

+1 to this request. Go's plugin system imposes so many requirements (although valid) to the point that it's usually a lot easier and robust to build everything together to form a single binary.

Apart from the hashicorp's go-plugin approach, which uses RPC to handle this problem, maybe another alternative is to learn from caddy, a popular web server which also supports external "plugins/modules":

The idea is to expose importable Main and RegisterLinter(i LinterInterface) functions from golangci-lint, and then the private linters should have an init function that calls RegisterLinter to register itself to golangci-lint. After these are done, building a custom binary is super simple by just having a temporary Go module with a main.go like the following:

import (
  golangcilint "github.com/golangci-lint/golangci-lint"
  // For the side effects only (i.e., the init function to register itself to golangci-lint).
  _ "your.private.linter/package/that/implements/theinterface" 
)

func main() {
  golangcilint.Main()
}

The dependencies of golangci-lint and your private linter will be automatically handled by the Go build system (since now golangci-lint and your private linter are just dependencies of the temporary Go module).

These build steps are also automatable because it doesn't need to modify any parts of golangci-lint's, as well as your private linter's code. You can even write a script or tool for it (which is exactly what xcaddy does).

This sounds a little more complicated than the current approach, but actually makes it a lot more automatable to build a custom (single) binary.