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 go run anything.go from a particular module (in your example, the parent), what matters is the working directory of the go run command, not where the source file was found. The fact that it is in a directory with a different go.mod is not relevant.

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.

@y3llowcake, this seems to be working as designed.

The main module is always the module containing the working directory of the go command invocation. When you pass a list of .go files explicitly on the command line, those files should be compiled as if they are a distinct package within the main module, and the main module's dependencies are updated such that the command you just invoked will be reproducible.

In contrast, you should find that go run ./submod produces an error due to crossing a module boundary.