What does go:go_module_declares_path_as_required_as mean?

The downloaded go.mod identifies a different module path from the path required by your dependency graph. Check renames, casing, forks, and replacements.

Go error: module declares its path as but was required as

Q: How do I prevent go:go_module_declares_path_as_required_as in CI?

Treat the module path as part of a published API and plan repository moves accordingly. Make fork identity and tagging policy explicit before other projects depend on it. Review `replace` directives as code changes, not invisible URL redirects.

Fix it fast

Most likely: A rename, fork, case change, or replacement made the required path disagree with the module directive.

Confirm this is your error

Match the output and confirm you are troubleshooting the same failure.

go: github.com/golang/lint@v0.0.0-20190313153728-d0100b6bd8b3: parsing go.mod:
	module declares its path as: golang.org/x/lint
	        but was required as: github.com/golang/lint
go: rsc.io/quote@v1.5.2: parsing go.mod:
	module declares its path as: rsc.io/Quote
	        but was required as: rsc.io/quote

Check the cause

Run focused checks to identify what is failing in this environment.

go mod why -m <required-path>
go list -m -json <required-path>@<version>
go env GOWORK

Apply the safe fix

Use the smallest safe change that addresses the confirmed cause.

# Canonical rename only: update imports to the declared path, then:
go get <declared-path>@<version>
go mod tidy

# Intentional fork: keep upstream imports and correct the replace target or fork module line.

Verify it works

Repeat the relevant checks and confirm the original error is gone.

go list -m all
go mod tidy
go build ./...

What This Error Means

Read this as a precise clue about which part of the workflow broke first. Once you know the failing layer, the fix path gets much shorter.

How to Fix It

The fastest fixes here come from checking the immediate failing layer before you change anything unrelated. Make one correction at a time and re-test from the same environment.

Canonical rename:update imports and requirements to the maintained module’s declared path.

Intentional fork:keep upstream imports, use replace <upstream> => <fork> <version>, and ensure the fork declares either the upstream or replacement path.

Incorrect replacement:remove or correct the replace directive, then review the resolved module graph.

Case or suffix mismatch:use the exact declared module path everywhere.

Transitive old path:upgrade the dependency that still requires it instead of adding permanent aliases.

Why It Happens

Consumers still require an old path after a repository or module rename.

A fork is imported under the fork URL even though its module line still declares the upstream path.

A versioned replacement declares a path matching neither the original module nor the replacement target.

Case or an unnecessary .git suffix changed the required module identity.

Verify the Fix

Run go list -m all and confirm only the intended module identity appears.

Run go mod tidy and the original build. Confirm they do not introduce both module paths.

Compare required, declared, and replacement paths

Copy both paths exactly, including case, and inspect the dependency’s go.mod at the selected version.

Run go mod why -m <required-path> and inspect require and replace directives in both go.mod and an active go.work.

Compare CI module files and GOWORK with a working environment.

Check for a rename, fork, vanity path, or changed module directive.

How Go enforces module identity

Go compares the fetched go.mod module directive with the path requested by the graph. Case, renames, forks, vanity paths, and replacements can create different identities. Go does not silently alias paths. Inspect the exact replace form because local-directory and versioned replacements behave differently.

Prevent It From Coming Back

To prevent this, treat the module path as part of a published API and plan repository moves accordingly, make fork identity and tagging policy explicit before other projects depend on it, and review replace directives as code changes, not invisible URL redirects.

Docs and source code

Go module file loader source

Current source for the declared-path versus required-path diagnostic. - Source

The loader compares the module directive with the path required by the graph.

Go Modules Reference

Official reference for module files, version selection, proxies, private modules, checksums, workspaces, and vendoring. - Source

The go command uses module paths and versions to resolve, download, and authenticate dependencies.