How to use gometaliner for projects with go modules and no vendor?

[moorara]

Currently, I have a repo which uses go modules and does not vendor its dependencies.
When running gometalinter, I get the following errors:

../../../../../go/pkg/mod/github.com/stretchr/testify@v1.2.2/assert/assertions.go:19:2:warning: could not import github.com/davecgh/go-spew/spew (cannot find package "github.com/davecgh/go-spew/spew" in any of: (unused)
../../../../../go/pkg/mod/github.com/stretchr/testify@v1.2.2/assert/assertions.go:19:2:warning: could not import github.com/davecgh/go-spew/spew (cannot find package "github.com/davecgh/go-spew/spew" in any of: (megacheck)
../../../../../go/pkg/mod/github.com/stretchr/testify@v1.2.2/assert/assertions.go:19:2:warning: unused variable or constant could not import github.com/davecgh/go-spew/spew (cannot find package "github.com/davecgh/go-spew/spew" in any of: (varcheck)
../../../../../go/pkg/mod/github.com/stretchr/testify@v1.2.2/assert/assertions.go:20:2:warning: unused variable or constant could not import github.com/pmezard/go-difflib/difflib (cannot find package "github.com/pmezard/go-difflib/difflib" in any of: (varcheck)
../../../../../go/pkg/mod/github.com/stretchr/testify@v1.2.2/assert/assertions.go:19:2:warning: could not import github.com/davecgh/go-spew/spew (cannot find package "github.com/davecgh/go-spew/spew" in any of: (gosimple)

And this is because linters go and lint the cached versioned of dependencies specified in go.mod and go.sum.

Is there any way we can exclude these dependencies from being linted the same way we ignore vendor path?

[envygeeks]

GO111MODULE=on gometalinter -I '^file.go' file.go

[haydenwoodhead]

I am having the same issue. I do have a vendor directory but gometalinter is skipping that and appears to be checking files in the /pkg/mod/ dir.

I'm simply running gometalinter --vendor ./...

[dnephin]

I believe you may be misunderstanding the problem. The errors above are failures to load the source, not lint errors. Ignoring the errors is not what you want, because they indicate that linting is not being performed due to a failure to load the source. If you were to ignore them you would not be linting the source files. This is unfortunately not obvious from the errors returned by most linters (or at least not from how they are printed by gometalinter).

I just started trying out go1.11. What I've done so far is something like this:

GO111MODULE=on go mod vendor
GO111MODULE=off gometalinter ./... 

I believe that is working correctly, but I haven't done much work to verify that all lint problems are being caught.

[envygeeks]

It won't work, what I had to do was create a script called rgo to go mod download and then scrap go.mod and install the dependencies globally, otherwise it wouldn't work, with... or without vendor. This also fixed goimports but the goimports issue is soon to be fixed as a merger was recently made to add support for go mod

#!/bin/bash
[[ "$DEBUG" ]] && set -x
set -e

mod=$GO111MODULE
sudo rm -rf ~/.go
export GO111MODULE=off
go get -u github.com/alecthomas/gometalinter
gometalinter --fast --install

if [[ "$mod" == "on" ]] || ([[ "$mod" == "auto" ]] && [[ -f "go.mod" ]]); then
 	export GO111MODULE=$mod
 
	go mod download
 	mods=$(cat go.mod | grep -E '^(\t|\s)+' | grep -v '// indirect' | sed -e 's/^[[:space:]]*//g')
 	echo "$mods" | while read l; do
 		d=$(printf "$l" | awk '{ print $1 }')
 		GO111MODULE=off go get -u "$d"
 	done
else
 	go get -u ./...
fi

[alecthomas]

gometalinter --fast --install

FYI this is deprecated and will stop working eventually.

[pkopac]

We used gometalinter until now as part of our CI, too, but were forced to disable it yesterday, because introducing go module meant it either couldn't find some libraries or tried to linter Go libraries.
Fun story, one dependency change broke another: heroku/rollrus#20

I don't have time to research a complete fix, but it would be great to have the support for Go 1.11 modules eventually. I'd be really happy even for partial support, eg. if we could enable just a few checks and add others later. Please, let me know if I can help somehow.

Is there a migration strategy/list of supported checks anywhere?
Is there an implementation ticket to subscribe to (besides this one)? So we know when the support is released to reintroduce it back into our projects?

Thank you!

[envygeeks]

go imports now supports modules, so it's only a matter of time before dependencies of gometalinter do too, I would assume pretty soon now that Go team is actively making sure modules support is upstream in the libs a lot of this stuff relies on.

[jirfag]

@pkopac you can work in GOPATH and use go mod vendor to make gometalinter work

[alecthomas]

To be clear, whether a linter does or does not work with modules has nothing to do with gometalinter.

The upstream tools need to be modified to support modules. You can track the official Go issue tracking various tool's here.

If a tool supports modules and has not been re-vendored into gometalinter, please send a PR to do so.

[bufdev]

I think you need to a bulk update for this - I just went to try out gometalinter, but so many of the linters failed due to not working with Golang Modules that it's not going to be possible to integrate it. Linters like errcheck have recently been updated to work with Golang Modules, and there is a lot of active work on this issue.

I don't know if OSS contributors will update all the linters - can you do a bulk update? Would be super appreciated.