I am obviously missing something very fundamental, but I don’t see any obvious way out of this.
We’ve got a very large monorepo with a single go.mod. For the purpose of handling incremental dependencies, we’d like to break out some submodules within this.
Let’s create a parallel example scenario for simplicity:
- module
example.com/hello - It’s in github, been building and tagging for a while.
Meanwhile, in my sandbox, let’s break out the foo package, so at the foo directory, adding a new go.mod and thus has package path example.com/hello/foo
And because I want to test build using the local version of the new sub-module, we’ll create a go.work at the root directory of example.com/hello (where its root go.mod is)
go 1.24.3
use ./foo
Now the problems start. Because foo has other packages that import other packages within the foo/ hierarchy, these imports become ambiguous and give errors during go mod tidy in the new foo sub package. tidy complains the foo packages are now both in example.com/hello and example.com/hello/foo.
Further, if I try to go mod tidy in the root package, code importing foo complains there’s no latest version. Well, of course not, it’s just in my local sandbox so far, and isn’t that what the workspace is supposed to take care of?
So I seem to be stuck in this circular can’t-get-there due to the fact the main repo already has tags, the workspace isn’t properly selecting the new local sub package, and the sub package is confused by the ambiguous situation between itself locally and what’s been tagged.
What am I doing wrong? Is what I am trying to do even possible?
Please no debates about sub packages in monorepos. We have our reasons.