Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/go: broken go.mod resolution across modules #31345
What version of Go are you using (
If you put multiple modules in a repository they are considered completely unrelated as far as requirements. The repo ends up just being a container for two independent things. In particular, when the "parent" imports something from the "child", it imports a fresh copy downloaded as any other module; it does not care that there is a working copy in a subdirectory.
Similarly, when you run
I am skeptical that you really want to be using multiple modules in the repo. You probably don't.
Switching to vscode helped me work around this issue, since it takes directory into account when running tools.
I also use Repos as containers for multiple modules. This allows me to break down a large module/package into a few smaller modules/packages, each with it's own set of dependencies clearly documented in each go.mod.
A parent module is then just referencing sub modules for it's own dependencies. (using the go.mod 'replace' directive during development makes this a lot easier to work on the submodules at development time, but it would be nice if this work-around wasn't required).
But maybe the tools could be a bit more verbose about what they are assuming and doing. eg I had another situation where the tools were trying to download a dependency that was local only (using the 'replace' directive), and strange error messages after a module rename, when the tools were still searching for the old name. Both with multi-module projects.
Maybe I have just spent too many years working with dependency tools like Maven where parent modules is a very common pattern.
For context I am experimenting with golang 'monorepo' repository structures.
Multi-module seemed to allow owners of a service/project/component to have more control over their dependency versioning, but seems confusing and unadvised as evidenced by this bug.
A single module repo is workable for us. I think we can even achieve allowing different components to run different versions of third party dependencies by using 'replace' directives. The only annoyance is that we must manage all of this from a single file at the root of a repo, there does not seem to be a clean way to create a hierarchy that works well with an OWNERs file system.