[Refactor] Update Go module paths to use standard 'github.com/...' convention

[ElecTwix]

Community feedback pointed out that our current module paths (e.g., 'the-dev-tools/server') are not idiomatic and prevent the packages from being 'go get'-able by other developers.

Current: 'the-dev-tools/server'
Target: 'github.com/the-dev-tools/dev-tools/packages/server' (or similar)

Action Items:

1. Update 'go.mod' files in all packages and apps.
2. Update imports across the codebase.
3. Ensure 'go.work' continues to resolve paths correctly for local dev.

[eikemeier]

Also using a workspace for building might not be a good idea:

It is generally inadvisable to commit go.work files into version control systems ...

CI systems should generally not be allowed to use the go.work file ...

https://go.dev/ref/mod#go-work-file

[ElecTwix]

Thanks for heads up about go.work @eikemeier, didn't realize that was the recommendation.

So for our case we need builds/tests to work offline in CI without hitting the network. Would replace directives be the way to go here?

Something like:

require github.com/the-dev-tools/dev-tools/packages/server v0.0.0
replace github.com/the-dev-tools/dev-tools/packages/server => ../../packages/server

That should resolve locally via relative path, and external users doing go get would just ignore the replace and fetch from GitHub.

Is this the typical pattern for multi-module monorepos or is there something cleaner?

[eikemeier]

So for our case we need builds/tests to work offline in CI without hitting the network. Would replace directives be the way to go here?

The point here is that developing locally is one thing, while publishing is another. When the two modules are tightly coupled, why version them differently? You can place non-public code in an internal directory and do whatever you want there.

Every module — even within a monorepo — is versioned separately. What’s your reasoning for using multiple modules?

Is this the typical pattern for multi-module monorepos or is there something cleaner?

I’m not sure what your specific targets are, but you can look at the structure of golang/tools. It includes gopls, which is a quite popular.