lint: Enable interfacer

[siggy]

interfacer suggests narrower interface types:
https://github.com/mvdan/interfacer

Part of #217

Signed-off-by: Andrew Seigner siggy@buoyant.io

[rmars]

https://github.com/mvdan/interfacer appears to be archived. should we find a currently maintained version of this? is the archived version still considered the recommended one?

[siggy]

yeah... we're limited to what golangci-lint provides. in some cases they maintain their own forks:
https://github.com/golangci/golangci-lint/blob/master/go.mod#L13-L29
...and in other cases they depend directly on other linters:
https://github.com/golangci/golangci-lint/blob/master/go.mod#L57

i think it's a worthwhile trade-off to defer to golangci-lint on linter selection, as it's fairly well-supported as a whole, and also quite fast compared to running each linter separately.

[alpeb]

Sometimes even if a type is more specific than necessary, it seems to me it can give more clarity, and even more type safety. Like with url *url.URL we're sure we're dealing with a URL, but the tool suggests url string, which can be anything.
Also something like client *http.Client sounds more conventional to me than client rest.HTTPClient.
So not sure if we should abide by this tool. Would love to hear what folks think though.

[rmars]

@alpeb I had the same thoughts! esp regarding url.URL and string! I do feel like for some of the changes here, the unlinted type was more informative.

[siggy]

@alpeb @rmars This all sounds reasonable. I think for a lot of these linters, there are tradeoffs where the linter requires slightly less-intuitive code at the benefit (hopefully) of easier code review. After reading your comments, I agree the linter benefits do not outweigh the code changes required. I'll close this one. Thanks for the thoughtful feedback!