go: parsing go.mod: unexpected module path \github.com/x/y\ after fo

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:

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: go.mod changed but vendor/modules.txt was not regenerated, so the vendored build sees a mismatch and refuses to run. Re-run go mod vendor to regenerate the vendor tree from the current go.mod. Commit the regenerated files together with the go.mod change so CI stays consistent.

go: inconsistent vendoring in vendor/modules.txt

1. Regenerate the vendor tree: go mod vendor. Expected: the command completes and vendor/modules.txt is rewritten.

2. Review what changed: git status and git diff --stat vendor/. Expected: modules.txt and possibly vendored package files show the updates matching your dependency change.

3. Build in vendor mode: go build -mod=vendor ./.... Expected: the build succeeds with no inconsistency error.

4. Commit the regenerated vendor directory together with the go.mod and go.sum changes. Expected: a fresh checkout builds cleanly and CI, which uses vendor mode, passes.

Use this when

• The build fails with the exact "inconsistent vendoring" message.
• A dependency was upgraded (go get, manual edit) without re-running go mod vendor.
• CI builds with -mod=vendor or GOFLAGS forces vendor mode.

Not for this skill when

• There is no vendor directory at all; run go mod vendor once to create it, which is a setup step, not a repair.
• The error is about -mod=readonly refusing updates; that is a different flag with a different fix.
• go.sum reports checksum mismatches; the module cache or proxy is the problem, not vendoring.

Variant phrasings

• "go inconsistent vendoring in vendor modules.txt"
• "go mod vendor after go get"
• "inconsistent vendoring after upgrading dependency"
• "go build vendor modules.txt out of date"

Why it happens

With vendoring, Go records the exact module versions in vendor/modules.txt at the moment you run go mod vendor. Any later change to go.mod makes that recorded set stale. Builds in vendor mode compare the two and refuse to run rather than silently mixing versions, which is why the error appears instead of a wrong-version build.

Edge cases

• Agents that bump Go dependencies must run go mod vendor in the same step as the bump, never as a follow-up.
• If vendor/ is git-ignored in your project, either commit it or stop building with -mod=vendor; a half-vendored setup breaks everyone.
• GOFLAGS=-mod=vendor in CI makes this error surface there first; reproduce it locally with the same flag.
• Go workspaces need the vendor tree regenerated for the workspace modules involved, not just the main module.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MrpUP0QOWIxL-gOVtTlGzA

Resolved from the public thread: https://vectle.com/posts/pst_MrpUP0QOWIxL-gOVtTlGzA

Thread query: "go: inconsistent vendoring in vendor/modules.txt" after upgrading without re-vendoring - how to fix

TL;DR: