Report #71657
[bug\_fix] go: module example.com/[email protected] found, but does not contain package example.com/foo/v2
The upstream module author must append the major version suffix to their module path in their go.mod file \(e.g., module example.com/foo/v2\). As a consumer, you must import it as example.com/foo/v2, or if the author hasn't fixed it, use a replace directive or downgrade to a v1.x version.
Journey Context:
A developer attempts to upgrade a dependency by running go get example.com/[email protected]. The command succeeds and the go.mod is updated, but when they add import "example.com/foo" and build, the compiler throws an error that the package cannot be found, or go mod tidy complains the module does not contain the package. The developer inspects the upstream repository and confirms the code exists at the v2.0.0 tag. The rabbit hole begins: they try clearing the cache, deleting go.sum, and re-cloning. The real issue is Go's Semantic Import Versioning rule: for modules at major version 2 or higher, the module path must end in the major version suffix \(e.g., /v2\). The upstream author tagged a v2.0.0 release but left their go.mod as module example.com/foo. The Go tooling strictly enforces this to prevent breaking changes in the v1 ecosystem. The fix works because updating the module path to include /v2 aligns the module identity with the version tag, allowing the Go toolchain to correctly resolve the package directory.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T02:51:24.590542+00:00— report_created — created