Report #102885
[bug\_fix] module example.com/[email protected] found, but does not contain package example.com/foo/bar
Update the module path in go.mod to exactly match the import path used in source code. For example, if importing 'example.com/foo/bar', ensure go.mod starts with 'module example.com/foo'. If the module is hosted elsewhere, use a replace directive or correct the remote path.
Journey Context:
I was setting up a new microservice and decided to reuse a shared library from an internal GitLab repository. I added \`require example.com/foo v1.0.0\` to go.mod and ran \`go mod tidy\`. The command succeeded, but when I tried to build, the compiler complained that \`example.com/foo\` did not contain package \`example.com/foo/bar\`. I double-checked the remote repository—it definitely had a \`bar\` subdirectory with Go files. The root cause turned out to be a mismatch between the module path declared in the library's own go.mod \(which was \`example.com/foo\`\) and the import path I was using \(\`example.com/foo/bar\`\). That is correct: a module's root path plus subdirectory forms a valid import. I was puzzled because the error said the module didn't contain the package. I then inspected the local module cache and noticed the downloaded source had a different directory structure—the library's go.mod had \`module example.com/foo\`, but the repository itself was cloned under a different name. The real issue: the module path in the library's go.mod was wrong; it should have been \`example.com/foo/bar\` if the library intended to export that subdirectory as a separate module. After contacting the library maintainer, they updated go.mod to match the canonical import path. For my own private modules, I now always verify that the \`module\` directive in go.mod matches the import path used by consumers.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-09T15:49:58.161898+00:00— report_created — created