I just started breaking up my app into different repos. Like many I'm going through the hassle of dealing with Go and changing repos. but there are many Q&A's on those issues so I won't ask about it here.
Instead, I have simple question but one that I can't make sense of. All my modules, because it was one big app., are just local references. E.g., core/validate and so on.
Moving things into multiple repos. seem to cause issues with local references so I'm changing the paths to remote paths like gitlab.com/<group>/core.git/validate as a couple of Q&A's have suggested.
However, this leads to a question, if say, gitlab.com/<group>/core.git/config has a reference to gitlab.com/<group>/core.git/validate doesn't that mean that gitlab.com/<group>/core.git/config is now pointing to either something in pck/mod/gitlab.com/... or to the remote server, or anywhere but each other like they were when they just had relative paths like core/validate? It looks that way when I change them because then my IDE (GoLand) shows references that aren't found.
I haven't tried to do a go mod init and rebuild mod from scratch but go mod tidy doesn't work and I don't know if I'm also going to have to make a change in go.work as well with the remote paths but right now I'm just getting imports not found showing in my IDE.
It also seems that if you are using remote references that for a change you make in your code when you are developing that you would have to push your change so it was where the references are pointing and maybe also do a go get for that change to be wherever locally remote paths are referenced which seems like a terrible way to develop so that can't be right.
So, what am I missing with how these remote paths work with development?
There are several concepts that cause confusion.
A module is a collection of packages. You can name a module like "mymodule", and then all the packages under "mymodule" will be named as "mymodule/pkg1", "mymodule/pkg2/otherpkg", etc.
Then you have an import path for a package. The import path shows the location of the package. For instance, your source code is in "mymodule/pkg1", and you import "mymodule/pkg2", then this is a reference to the package under the same module.
Now let's say you have another module, named "othermodule", on "github.com/mygroup/othermodule". You import a package in this module as "github.com/mygroup/othermodule/pkg1". If "othermodule/pkg1" refers to "othermodule/pkg2", then it still imports "othermodule/pkg2", because it is in the same module. But from "mymodule/pkg1", you import it as "github.com/mygroup/othermodule/pkg2".
Go module system uses version references to other modules. When you include a package from a module, a particular version of that module is added to go.mod. If you push new changes to that module, you have to update that reference to include those. That's the reason why it is best not to separate tightly coupled projects into multiple modules.
If you want to develop multiple modules together, then use "replace" directive to use a local copy of that module, instead of pointing to the version on a repository.