AutoComplete un-imported packages based on go.mod

[uudashr]

Initial support for go modules.

[ramya-rao-a]

Thanks for jumping on this @uudashr!

Correct me if I am wrong, I was under the assumption that when modules are enabled, then one can only import packages that are defined in the module or the ones in the standard library.

With the current change, packages from the GOPATH will also be included regardless of whether the current file is under the GOPATH or not

[uudashr]

Ya.. correct. Just figure out.
Need to remove all the packages from GOPATH, should only shows from GOROOT.

For more fine-grained control, the module support in Go 1.11 respects a temporary environment variable, GO111MODULE, which can be set to one of three string values: off, on, or auto (the default). If GO111MODULE=off, then the go command never uses the new module support. Instead it looks in vendor directories and GOPATH to find dependencies; we now refer to this as "GOPATH mode." If GO111MODULE=on, then the go command requires the use of modules, never consulting GOPATH. We refer to this as the command being module-aware or running in "module-aware mode". If GO111MODULE=auto or is unset, then the go command enables or disables module support based on the current directory. Module support is enabled only when the current directory is outside GOPATH/src and itself contains a go.mod file or is below a directory containing a go.mod file.

[ramya-rao-a]

So I am guessing we need to

• Identify if current package is using modules or not
• If it uses modules, then we can run go list with the GOROOT as cwd and combine the results with that of go list -m all with current package as cwd.

The identification of whether current package is using modules or not, should be done in util.ts file just like getGoVersion

[ramya-rao-a]

I cloned https://github.com/golang/example/ outside of my GOPATH

• Ran go mod init and go mod tidy in the example folder
• cd hello and go build to ensure that the hello package builds without any issues
• The file hello/hello.go imports the stringutil package, but if I run go list -m all, the stringutil is not listed.

Since this PR relies on go list -m all, how is the above case going to be supported?

[uudashr]

@ramya-rao-a what is the goal of browsePackages() we need to decide what it should shown on the browsePackages() under Go 1.11, is it the all packages on the GOROOT + GOPATH?

What if we are opening file under go modules project, does the result going to be different ex: GOROOT + modules

[ramya-rao-a]

Yes. Let's keep things consistent and make all the 3 exported functions from goPackages.ts to

• return packages from GOROOT and GOPATH if current package is under GOPATH
• return packages from GOROOT and modules if modules feature is being used

[dreamheld]

Is this coming online soon? It'd be nice for VSC to work with the .mod files!

[uudashr]

Hopefully soon

[dreamheld]

Hopefully soon

Eh! I just went ahead and imported your files into my current Go plugin. Couldn't wait for the 'official' release. Great work, man! Everything is working just swimmingly! Love it!

[edp1096]

Works great too.
I'm using inferGopath and using original GOPATH as only an area of extension's gotools.

[ramya-rao-a]

@uudashr Turns out that if you use go list all without the -m flag, it gives you all the available packages for the current module. So we don't need to first fetch all the std lib and then join it with the result of go list -m all.

Also, the current solution in this PR doesn't make use of the caching system we put in place earlier.

I am closing this PR in favor of 0a9001f which covers the above concerns.

Do take a look at that commit and share any feedback you have.

Others,
Please do try the latest beta version of this extension which has the above fix and share any issues you find.

Also see
#1532 (comment)

[uudashr]

Still we have missing piece here.
go list -m all show the list of modules not packages.

[ramya-rao-a]

Note to others: this is being followed up in #1937