Go workspaces
Use `go.work` for multi-module local development, not as the published dependency contract consumers rely on.
Canonical guidance
- use
go.workwhen developing several modules together - keep each module’s
go.modauthoritative for consumers - treat the workspace file as local coordination, not public version policy
Use when
- monorepos with several Go modules
- coordinated local refactors across modules
- testing unpublished module combinations
Avoid
- assuming CI or consumers must use the same workspace
- using
go.workto hide broken module requirements - letting unrelated experimental modules leak into the workspace
Preferred pattern
go work init ./lib ./service
go work use ./tools
Anti-pattern
- depending on
go.workto make a module build because itsgo.modno longer states the real requirements
Explanation: This anti-pattern is tempting during local iteration, but it breaks reproducibility for everyone outside the workspace.
Why
- workspaces are for local multi-module editing, not for published dependency contracts
Related pages
Sources
- Go Modules Reference - Go Team
- go command - Go Team