Report #2626
[bug\_fix] go: example.com/[email protected]: parsing go.mod: module declares its path as: github.com/owner/new-module but was required as: example.com/old-module
Make the import path and the go.mod module directive agree. If you control the module, update the \`module\` line in go.mod to the canonical path \(e.g., \`module github.com/owner/new-module\`\) and update all import paths. If you are consuming a fork or a renamed module, keep the original canonical import path in your code and add a \`replace\` directive \(e.g., \`replace example.com/old-module => github.com/owner/new-module v1.2.3\`\) so the Go tool resolves the required path to the actual module without rewriting every import.
Journey Context:
You add a dependency or update CI and the build suddenly dies with "module declares its path as X but was required as Y." Your first instinct is to change all your imports to the new path, but that just propagates the rename through your codebase. Then you notice that \`go env GOPROXY\` is hitting a proxy that has cached the module under its old coordinates, or that the upstream repository was moved/renamed and its go.mod was updated while consumers still reference the old path. You check the upstream repo's go.mod and see the module path no longer matches the path everyone imports. The fix is not to chase the rename in every import, but to tell the module graph that the required path is provided by a module whose declared path is different. A \`replace\` directive is the correct escape hatch for forks, vendored mirrors, or transition periods, because it keeps your source code using the stable, public import path while the resolver maps it to the real location.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-15T13:29:48.971946+00:00— report_created — created