go: module github.com/x/y@v1.2.3 found, but does not contain package github.com/x/y/z" - how to fix
Fixes the Go error where a module resolves at a version but the requested package is not inside it. Use it when go build or go mod tidy fails with the does-not-contain-package message after a dependency bump. Key trigger: the module's own go.mod declares a different module path than the one you required, most often a missing /v2 major-version suffix.
TL;DR: The module downloaded fine, but its own go.mod file declares a different module path than the one you asked for, so Go cannot find the package inside it. Check the module's declared path in the module cache and fix your require line to match it. This most often means you need the /v2 suffix on both the require and the import path.
The error
"go: module github.com/x/y@v1.2.3 found, but does not contain package github.com/x/y/z" - how to fixSteps to fix
Run: go list -m -versions github.com/x/y (replace with your module path) to confirm which versions the proxy knows about. Expected: A list of version numbers prints, confirming the module exists and v1.2.3 is published.
Download the module and read its declared path: go mod download github.com/x/y@v1.2.3, then open the go.mod file inside the module cache at the path shown by go env GOMODCACHE. Expected: The first line reads something like module github.com/x/y/v2, which does not match the path you required.
If the declared path ends in /v2 (or any /vN), update your go.mod require to github.com/x/y/v2 v2.x.y and change your imports to github.com/x/y/v2/z. Expected: go build succeeds and go mod tidy reports no changes needed.
If the declared path matches but package z is missing, list what the version actually ships: look inside the cached module directory for the z folder. Expected: You either find that z was renamed or removed in v1.2.3, and you pin an older version or update the import to the new package path.
Use this when
- go build, go mod tidy, or go get fails with does not contain package right after a version bump
- You forked or renamed a repo and the module path in go.mod no longer matches the import path
- A dependency moved to v2 or later and you kept requiring the un-suffixed path
Not for this skill when
- go: module not found errors, which mean the module path or version does not exist at all
- Checksum or go.sum mismatch errors, which are integrity problems, not path problems
- Private-module authentication failures (410 Gone or auth errors from the proxy)
Variant phrasings
- go mod tidy says module contains no packages
- go get fails with missing go.sum entry after a bump
- import path does not match module path in go.mod
Why it happens
Go identifies a module by the module line in its own go.mod, not by the repository URL you typed. When a project releases v2 or later it must declare the /v2 suffix in that line (the major-version suffix rule). If you require the bare path, Go finds the module files but the declared identity does not match your request, so every package lookup inside it fails. The same message appears when a package was genuinely deleted or renamed between versions.
Edge cases
- Some projects publish v2 tags without updating the module line; then the fix is on their side and you pin the last good v1 instead.
- A replace directive pointing at a local fork can mask this; check go.mod for replace lines before changing versions.
- After fixing the path, run go mod tidy to drop the stale require, or the old line keeps shadowing the new one.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_GPRMSGY0LzOrK8VPffIlGA