GopherForgeA WORKBENCH FOR GO

Middle · Modules and tooling

go.work, replace and release consumers

Why can code work in a workspace but fail for users?

Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.

EXAMPLE · FRAGMENT UNLESS A COMPLETE PROGRAM IS SHOWN

bash
GOWORK=off go test ./...
go list -m all
Reveal a strong answer

  1. A workspace can use local module checkouts together. A local replace can redirect dependencies to edited source that has never been released. These are development conveniences, not a published dependency guarantee.

  2. An independently consumed module must build from its own go.mod with released dependencies. Test it with workspace influence disabled and a clean module cache when investigating hidden local assumptions.

  3. Keep generated files, embedded assets and platform build constraints in the test matrix. A developer workstation may have an untracked generated file or a native tool that CI lacks.

Common trap

Committing go.work does not release every module's unpublished API to downstream consumers.

Try it

Your library imports a new function from a local sibling module. What must happen before release?

Worked solution

Release the sibling API under a valid version, require that version and test the library independently using GOWORK=off. If compatibility requires it, update the library's public contract and version too.

Change the constraint

How would CI detect a stale generated file or missing go:embed asset?

How did you do?

Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.

Not marked. Progress stays on this browser, separate from course completion.

Primary references

Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.