Report #7849
[bug\_fix] module declares its path as X, but was required as Y
Update the \`module\` directive in the dependency's go.mod to exactly match the import path, or update the import path in your code. If consuming a fork, use a \`replace\` directive in your go.mod pointing to the fork's repository while keeping the original module path in your code imports.
Journey Context:
A developer forks a repository on GitHub to fix a bug and pushes a tag. They update their project's go.mod with \`replace github.com/original/repo => github.com/fork/repo v0.0.0-...\` and run \`go build\`. The build fails with a path mismatch error. They spend hours checking Git tags, running \`go mod tidy\`, and clearing the module cache, suspecting a caching issue. The actual root cause is that Go strictly enforces that the \`module\` directive in go.mod matches the path used to fetch it. The fork's go.mod still says \`module github.com/original/repo\`. The \`replace\` directive only tells the Go toolchain \*where\* to download the source, but the toolchain still expects the downloaded go.mod to claim it is the original module. The correct fix is to keep the import paths in code as \`github.com/original/repo\` and use \`replace\` to fetch the source from the fork, without changing the fork's go.mod. This works because the Go toolchain verifies the module identity against the import path, and the \`replace\` directive satisfies the fetch location while preserving the identity.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T03:51:55.604319+00:00— report_created — created