Latest version of vscode-go is vetting all vendored code

[tylerstillwater]

This slows my system to a crawl. I've had to disable vet entirely.

See @ramya-rao-a comment in gitter here

About vet. Long long ago we ran go tool vet filename, then that changed to go vet . to stay consistent with build and lint which operate on package rather than single file. With this we noticed that the vet flags were getting ignored. So changed that to go tool vet .. Its the go tool vet . that is picking up the vendor folders. Do log a bug for this and we can see how we can fix it

I'd love to be able to run vet on just my own code.

[davecohrs]

I noticed the same issue. However, for me, the problem is worse. The code in the vendor directory does not pass "go vet", while my own code does pass. I ended up disabling vet because I could not control the paths that were being vetted.

[tylerstillwater]

@davecohrs same here. Thousands and thousands of results, rendering my problem pane pretty useless.

[ramya-rao-a]

I have pushed the fix to master.

Until I release an update, here is what you can do

• Download this vsix file: https://github.com/Microsoft/vscode-go/blob/master/Go-latest.vsix
• Go to extensions pane in VS Code and in the menu choose "Install from vsix", and select the downloaded vsix file when the finder/file explorer opens

[tylerstillwater]

Thanks @ramya-rao-a!

[ramya-rao-a]

The fix for vet picking up vendor folder is now out in the latest update to the Go extension (0.6.64)

[dtknut]

The fix in 0.6.64 does not solve the underlying problem that "go tool vet ." will pick up the vendor folder. This means vet takes 20 seconds on a project with only a single Go file (main.go). I think vet should not process the vendor folder at all. Ignoring the vendor folder in the results is not enough.

EDIT: This is only a problem in two cases:

1. when "go.vetOnSave" is set to "package" and the edited file is in the same folder as the vendor folder, typically main.go.
2. when "go.vetOnSave" is set to "workspace"

[ramya-rao-a]

@dtknut I agree, I wish there was a smarter solution

Here is the catch

• go tool vet takes a rich set of flags, but only takes a directory or set of files as parameters
• go vet does not take any of the flags like go tool vet, but can take set of packages as parameters

We currently use go tool vet because we allow users to set the flags via go.vetFlags
But this puts a restriction that I can only vet a directory
If it took a list of packages, then I could pass only the non vendor packages.

A few options I can think of are

• When "go.vetOnSave" is set to "package", we can add a check to not vet if current package is a vendor package. But I am curious here though... why would you want to edit a vendor file?
• When go.vetFlags is empty, use go vet instead of go tool vet and pass the non vendor packages to it.

If you were using the vet flags AND vetOnSave is set to workspace, I don't have a solution there.

Do you have any solutions in mind?

[dtknut]

@ramya-rao-a I am not sure there is a perfect solution.

Personally, I had vetOnSave set to package, but was editing a main.go file in the root folder. For this case one could maybe run go tool vet main.go to avoid picking up the vendor folder. I am not sure if this would cause any other issues. It is not exactly doing what package implies.

[ramya-rao-a]

@dtknut When set to package, go tool vet . is run on the parent folder of the file being edited.