Feature request: support Go plugins

[vitalyisaev2]

Hello! In our company we have some domain-specific linters and checkers and we would like to run it alongside with all the linters provided by golangci-lint during a single run, and configure them in a single .golangci.yml.

Since we can't publish code of our linters (and even if we did so, they would be pretty useless for upstream golangci-lint, there are only two ways left:

1. Make private fork of golangci-lint and merge our linters into your code base directly. This is a bad idea for obvious reasons.
2. Load our linters dynamically on golangci-lint startup. This is what Go plugins were designed for.

So it would be nice to have support of Go plugins here. Our linters will implement some interface and will be loaded as *.so files. What do you think about it?

Kind regards

[ernado]

Pluggable linters is a great feature, but I'm slightly concerned about overhead of maintaining stable API for them. Currently we can move internal things pretty quickly, but this can add some traction for new features.

Actually there is third way: load linters in compile-time while using golangci-lint as a framework, not a binary. This will require building the whole golangci-lint, but you will need to build plugins anyway.

What do you think about that approach?

[sirkon]

An author of aforementioned "domain-specific linters" here

Actually there is third way: load linters in compile-time while using golangci-lint as a framework, not a binary.

It looks like the best approach.

[csilvers]

@ernado That would mean we would need to re-implement some subset of the golangci-lint CLI, is that right? At least the flags parsing and so forth?

It also seems to me that for people who go with this approach, then when the golangci-lint internals change, these people will need to rewrite all their custom linters to match the new internals API, is that right?

[dbraley]

@ernado Should I take your reply to mean a PR allowing linters to be loaded as plugins would not be desirable? I've been working on that for a few days based on @jirfag comment on #473 (comment) . I was hoping to get the code cleaned up, write up a readme on how to implement and import plugin linters, and file the PR this week.

If said PR would not be desirable as the comment suggests, I can change course.

[ernado]

@dbraley of course it is desirable! Approaches does not exclude each other, so if we implement one, it will be easy to implement other.

Thank you for your effort! Personally I'm very exited to see results. I was not aware about somebody already implementing this.

@csilvers I think that we can implement framework in such way that manual parsing will not be needed.

[dbraley]

@ernado Thanks for the clarification! I'll keep working on that, hopefully have it ready soon!

[dbraley]

#841

[aymericbeaumet]

@jirfag @vitalyisaev2: I see that #841 is now merged, can we close this issue?

[denisdubovitskiy]

Hi there! The custom linter spec says that package versions need to be the same as in golangci-lint go.mod file, but how can I find a workaround if the dependent package gets upgraded during the compile time?

This plugin is very domain specific and there is no need to commit the code to the main golangci-lint repo.

go get does not respect -mod=readonly flag. Seems like it's almost impossible to have the same version of the dependant library in the linter using go modules.

d.dubovitskiy:project$ make build-lint
....
go: creating new go.mod: module temp
go: golang.org/x/tools upgrade => v0.0.0-20200612220849-54c614fe050c
go: downloading golang.org/x/tools v0.0.0-20200612220849-54c614fe050c
go build -buildmode=plugin \
                -o /Users/d.dubovitskiy/job/project/bin/custom-linters.so \
                github.com/somerepo/linters
...

d.dubovitskiy:project$ make lint

/Users/d.dubovitskiy/job/project/bin/golangci-lint run --new-from-rev=origin/master --config=.golangci.pipeline.yaml ./...
ERRO Unable to load custom analyzer span:./bin/custom-linters.so, plugin.Open("./bin/custom-linters"): plugin was built with a different version of package golang.org/x/tools/go/ast/astutil

UPD: does the golangci-lint support cli invocation? Seems like it can solve such problems with custom domain-specific linters

[ldez]

Closed by #841