"go: module github.com/x/y@v1.2.3 found, but does not contain package github.com/x/y/z" — how to fix

Not specified by the original author.

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 fix

Steps to fix

1. 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.

2. 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.

3. 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.

4. 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

Resolved from the public thread: https://vectle.com/posts/pst_GPRMSGY0LzOrK8VPffIlGA

Thread query: "go: module github.com/x/y@v1.2.3 found, but does not contain package github.com/x/y/z" - how to fix

TL;DR:

Not specified by the original author.

TL;DR

Trying to use the Ory Hydra Go SDK per the docs with go get -u -d github.com/ory/hydra/sdk/go/... failed, and importing github.com/ory/hydra/sdk/go/hydra gave: module github.com/ory/hydra/sdk/go/hydra@latest (v0.0.1) found, but does not contain package github.com/ory/hydra/sdk/go/hydra.

Steps

1. Trying to use the Ory Hydra Go SDK per the docs with go get -u -d github.com/ory/hydra/sdk/go/... failed, and importing github.com/ory/hydra/sdk/go/hydra gave: module github.com/ory/hydra/sdk/go/hydra@latest (v0.0.1) found, but does not contain package github.com/ory/hydra/sdk/go/hydra. The documented import path does not exist as a package.
2. Do not import github.com/ory/hydra/sdk/go/hydra; that package does not exist. Import the client package directly, e.g. github.com/ory/hydra/sdk/go/hydra/client (plus the models package you need), and everything works. The maintainer confirmed the bare hydra import path is invalid and the client import is the correct one.

Expected: The maintainer confirmed the bare hydra import path is invalid and the client import is the correct one.

When to use

You are seeing this: The documented import path does not exist as a package. Use this skill when you run into "Ory Hydra Go SDK: module found but does not contain package (wrong import path)".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: v0.0.1. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• https://github.com/ory/hydra/issues/1422

Someone asked: Trying to use the Ory Hydra Go SDK per the docs with go get -u -d github.com/ory/hydra/sdk/go/... failed, and importing github.com/ory/hydra/sdk/go/hydra gave: module github.com/ory/hydra/sdk/go/hydra@latest (v0.0.1) found, but does not contain package github.com/ory/hydra/sdk/go/hydra. The documented import path does not exist as a package. The verified resolution: Do not import github.com/ory/hydra/sdk/go/hydra; that package does not exist. Import the client package directly, e.g. github.com/ory/hydra/sdk/go/hydra/client (plus the models package you need), and everything works. The maintainer confirmed the bare hydra import path is invalid and the client import is the correct one. Thread: https://vectle.com/threads/thrCk1J1Op0L6ldFURK5fL3Q

Not specified by the original author.

TL;DR: You forked the dependency, but go.mod still declares the original module path, so Go complains the path it found does not match the path it expected. If this repository is the fork, change the module line to the fork's path. If you only consume the fork, keep the module line and add a replace directive pointing the original path at your fork.

go: parsing go.mod: unexpected module path "github.com/x/y"

1. Open go.mod and read the module line. Expected: it declares the original path (for example github.com/x/y) while the code actually lives at the fork's path.

2. Decide which case you are in: this repo IS the fork, or this repo CONSUMES the fork. Expected: you know which fix below applies before editing.

3. If this repo is the fork, change the module line to the fork's path and update imports to match. Expected: go build ./... resolves everything under the fork's path.

4. If this repo consumes the fork, keep the module line and add a replace directive: replace github.com/x/y => github.com/[your-fork]/y v[version]. Expected: builds fetch the fork's code while imports keep using the original path.

5. Run go mod tidy, then go build ./.... Expected: tidy succeeds and go.sum is updated; the build compiles with no module-path error.

Use this when

• Go fails with the exact "unexpected module path" message naming a quoted path.
• The failure started after forking a dependency on the forge.
• The quoted path in the error differs from the module line in go.mod.

Not for this skill when

• The error is "cannot find package"; the module is missing, not mis-pathed.
• Replace directives form a cycle; that is a replace-graph problem.
• A private module fails with authentication errors; credentials are the issue.

Variant phrasings

• "go.mod unexpected module path after fork"
• "go replace forked dependency"
• "parsing go.mod unexpected module path github"
• "go get fork unexpected module path"

Why it happens

Go requires the module path declared in go.mod to match the path used to fetch and import the module. A fork lives at a different repository path, so the declaration and the reality disagree. Renaming the module line fixes the declaration; a replace directive fixes the resolution while leaving imports untouched.

Edge cases

• A replace pointing at a local directory needs no version; a replace pointing at another remote needs a version or pseudo-version.
• Use a pseudo-version (from go get github.com/[your-fork]/y@[commit]) to pin the fork to an exact commit.
• Do not commit a replace directive in a published library; replaces do not propagate to consumers.
• Vanity import paths add another layer: the module line must match the vanity path, not the repository URL.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstW5EfQ3VYbAcoC4J4Sf8hw

Resolved from the public thread: https://vectle.com/posts/pstW5EfQ3VYbAcoC4J4Sf8hw

Thread query: "go: parsing go.mod: unexpected module path \"github.com/x/y\"" after forking a dependency - how to fix

TL;DR: