Support Go modules

[jbrodriguez]

Now that vgo is available (https://research.swtch.com/vgo-tour), vscode-go will remove imports flag errors because it doesn't understand the module (go.mod) concept, assuming you've configured golint to do that.

Other issues will come up as well and the only workaround I can think of is disable lint modules (possibly).

I'm putting this out there since this is something we will definitely require .

[alfred-zhong]

I read the blog and I like vgo, too. But I don't know if vgo should be supported soon.
Although vgo brings very good thoughts, it is still new and experimental. Also it hasn't been bringing into the offical toolchain (Maybe soon in go 1.11 or 1.12, I don't know). Now if you want to use vgo, the get and build commands should also be called from "vgo" command, but not the "go".

[nicpottier]

There's a bit of a chicken and egg problem here. To be honest I'd be using vgo today on my projects if I had support for it in vscode, just so much clearer and faster than dep, glide and co.. Happy to contribute if people want to point me in the right direction.

[jancona]

@nicpottier I've found that I can use vscode with vgo by placing my code at the proper GOPATH location (even though vgo doesn't use GOPATH) and using vgo vendor to put all my dependencies in the vendor/ directory. That way the regular go tools that vscode uses still work, and I can use vgo commands from the command line. By using vgo vendor I don't have to go get my dependencies.

[hackervera]

Looks like vgo is more serious now https://blog.golang.org/versioning-proposal

[illegalnumbers]

What would be needed to move forward on this? How does vscode-go map dependencies and how can we add that path matching on to this extension? Would love to help out.

[tyhi]

The vgo proposal was accepted earlier.

golang/go#24301 (comment)

[ramya-rao-a]

I dont have the expertise to work on this, but I can help anyone who wants to give it a shot.

@nicpottier, @illegalnumbers The Go extension does not maintain any maps of dependencies. It uses go build to get the compile time errors if any and then uses regular expressions to extract the filename, line and column numbers from the error message to create the errors that you see in the editor. See https://github.com/Microsoft/vscode-go/blob/0.6.80/src/goBuild.ts#L51

[nicpottier]

As far as I can tell the error format won't change with vgo, but what will is code navigation.. IE the path to find a specific package is no longer just $GO_PATH/vendor but a version specific path instead. Do you know where that kind of resolving is taking place?

[jrick]

vgo uses its own algorithm to determine the version, and the modules are extracted to $GOPATH/src/v/modulepath@version. You can see all of the currently-resolved modules and versions with vgo list -m.

[nicpottier]

Ah, right you are.. a sample:

% vgo list -m
github.com/jmespath/go-jmespath                v0.0.0-20160202185014-0b12d6b521d8
github.com/jmoiron/sqlx                        v0.0.0-20180406164412-2aeb6a910c2b
github.com/koding/multiconfig                  v0.0.0-20171124222453-69c27309b2d7
github.com/lib/pq                              v0.0.0-20180201184707-88edab080323

So the right version of pq is found in:

$GOPATH/src/v/github.com/lib/pq@v0.0.0-20180201184707-88edab080323

[jrick]

Note that modules can encompass multiple packages, so the github.com/lib/pq/certs package for example is part of the pq module since it shares the same longest module prefix of any referenced module.

Perhaps vgo should gain a way to query for just the resolved module, version, and perhaps even source directory of any arbitrary package. This would making integration with editors and IDEs simpler.

[nicpottier]

Agreed, might be useful to know from the vscode folks where the current code is for resolving these. Would make sure that whatever is added to vgo would satisfy that requirement.

[ramya-rao-a]

@nicpottier

For code navigation we use tools like godef and gogetdoc. The extension itself doesnt do any package resolution.

The only place the extension explicitly deals with vendors is to provide the Go: Add Import feature which lists all the packages available for import for the current file. Say there is a vendor package at github.com/me/myproject/vendor/github.com/you/yourproject folder. In a file github.com/me/myproject/main.go, this package will appear as github.com/you/yourproject when the Go: Add Import feature is invoked. Will this be affected by vgo?