Thanks for the comment! Yes, I saw golangci-linter. As the readme of the tool states, it's a linter aggregator, similar to gometalinter, with better performance characteristics. Both golangci-linter and gometalinter incorporate existing tools for static analysis and provide a facade on top.
Revive is a project, which I started about 9 months ago but recently found time to put some finishing touches and open source it. It's not a linter aggregator; it's a framework which provides tools for reducing the friction for development of custom rules for static analysis of your applications.
And no, the individual rules in revive do not parse the files. There's an abstraction on a higher level which parses the files ones. Each rule may request type information for the package which is then cached and reused across the invocations as well. That's how revive manages to improve the performance of golint to this extent.
Thanks for the clarification. I saw the readme, and I assumed (wrongly) that each rule just receive a file name.
I wonder where you draw the line between a "linter aggregator" and a "linter". golangci-lint incorporates all the rules themselves, though it imports the linter logic as libraries, so I'm not sure that it's fair to call it an aggregator. Gometalinter runs linters as child processes and I don't think it contains any linter code, so it's a pure aggregator.
My point is that while your project is admirable, the Go world isn't large enough for so many linter projects. Personally, I just want one good linter that is maintained and that incorporates all the rules I want.
Revive is a project, which I started about 9 months ago but recently found time to put some finishing touches and open source it. It's not a linter aggregator; it's a framework which provides tools for reducing the friction for development of custom rules for static analysis of your applications.
And no, the individual rules in revive do not parse the files. There's an abstraction on a higher level which parses the files ones. Each rule may request type information for the package which is then cached and reused across the invocations as well. That's how revive manages to improve the performance of golint to this extent.