x/tools/cmd/goimports: weird behaviours - not importing and removing dependencies automatically

[brunoluiz]

What version of Go are you using (go version)?

$ go version
go version go1.13 darwin/amd64

Does this issue reproduce with the latest release?

Yes, it does

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/brunoluiz/Library/Caches/go-build"
GOENV="/Users/brunoluiz/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/brunoluiz/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/brunoluiz/git/snapdiff/scheduler/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/46/73767m017_n8yfc849p52zpm0000gn/T/go-build095282659=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Using goimports -w file.go or through vim-go.

What did you expect to see?

Dependencies (external or internal) should be auto imported.

What did you see instead?

It doesn't auto-import packages from the same project/module, it doesn't fetch external packages and sometimes, even if I add import statements manually it scrapes it. Example: I am using strconv.itoa and even if I add strconv to imports statement, goimports removes it.

I thought initially it was a vim-go issue, but I've tried goimports -w file.go and it doesn't as expected.

Side note: if I run go get ..., it doesn't scrape the dependency.

[heschi]

I don't see anything suspicious in the provided go env output, and that's pretty much all there is to look at, so I have no idea what the problem is. Please provide a reproducer, or at least the output of goimports -v.

[bcmills]

CC @matloob

[brunoluiz]

I've re-tried now and it ?seems it works? (using goimports -w), although vim-ale still struggles to find the external dependencies. Can gopls influence any of this?

[brunoluiz]

Okay, I did some extra digging today. Basically, I have this mono-repo with all services for this project. If goimports is ran from the root, it leads to these weird stuff I've mentioned -- the same apply if I open vim in this folder.

When goimports is executed from ./service folder, then it works. Perhaps, if it is not in the root, it can't resolve the go.mod files from the sub-folders?

[heschi]

Yes, goimports uses all the same rules as the go command itself for module mode. You have GO111MODULE unset, so it sounds like you were getting goimports in GOPATH mode when running in the parent dir. That wouldn't work well unless you actually had your GOPATH populated with all your dependencies.

[brunoluiz]

What would be the behaviour of goimports if my GO111MODULE was on instead of auto?

[heschi]

It will be able to find things that are in the module cache, but probably not much else, since it won't know what the import path of anything should be without knowing the module in use.

Closing, since there doesn't seem to be a bug here. For better or worse, most module-aware tools need to be run in the right working directory.