New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: go mod tidy, vendor hide module load errors #27063

rsc opened this Issue Aug 17, 2018 · 3 comments


None yet
5 participants

rsc commented Aug 17, 2018

The module loader leaves some problems for the standard loader to find, like not being able to resolve imports. But 'go mod tidy' and 'go mod vendor' do not run the standard loader, so those problems go undiagnosed. Maybe we should look for them explicitly.

For example make a file x.go that says import "nonexist". go mod tidy succeeds quietly.

@rsc rsc added this to the Go1.12 milestone Aug 17, 2018

@rsc rsc added the modules label Aug 17, 2018

@rsc rsc changed the title from cmd/go: go mod tidy hides module load errors to cmd/go: go mod tidy, vendor hide module load errors Aug 18, 2018


This comment has been minimized.


kevinburke commented Sep 26, 2018

#27868 is possibly a duplicate of this issue; I'm not positive.


This comment has been minimized.

jsternberg commented Oct 9, 2018

We have run into this issue where using go mod tidy on a machine that doesn't have bzr, but that has bzr dependencies, will just not mention that it didn't work correctly.

We caught it because our CI system is now running go mod tidy and it has bzr installed.


This comment has been minimized.

gopherbot commented Dec 10, 2018

Change mentions this issue: cmd/go: fix 'go test' and 'go fmt' with files outside a module

gopherbot pushed a commit that referenced this issue Dec 11, 2018

cmd/go: fix 'go test' and 'go fmt' with files outside a module
Use the actual loader result in findModule instead of making
assumptions about nesting in the build list.
As a side-effect, this produces much clearer error messages for
packages that (for one reason or another) failed to load.

Adjust the package and module path outside a module to
"command-line-arguments". That string already appears in the output of
a number of (module-mode and GOPATH-mode) commands for file arguments,
and as far as I can tell operation outside a module is currently the
only case in which the module path of a package is not actually a
prefix of the import path.

Fixes #28011
Fixes #27099
Fixes #28943
Updates #27102
Updates #28459
Updates #27063

Change-Id: I61d5556df7b1b7d1efdaffa892f0e3e95b612d87
Run-TryBot: Bryan C. Mills <>
TryBot-Result: Gobot Gobot <>
Reviewed-by: Jay Conrod <>

@bcmills bcmills modified the milestones: Go1.13, Go1.12 Dec 12, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment