Migrate to dario.cat/mergo

Since v1.0.0, Mergo declares its module path as dario.cat/mergo. The GitHub repository location and the module's import path are different things. New code should import the declared module path.

Recognize the module-path mismatch

If an import or dependency still requires github.com/imdario/mergo but selects a v1 release, Go reports a module-path mismatch. Issue #248 records the transition failure. Its dependency discussion also explains why replacing the old path with the new one can fail when both are in the module graph.

A go get alone does not rewrite your source imports. Choose the direct or indirect dependency path below.

Direct dependency: change your imports

For code you maintain, replace imports of github.com/imdario/mergo with dario.cat/mergo, install the new module, and tidy your dependencies. The public API remains available at the new path, but run your application's tests to verify the behavior you depend on.

From the application's module root:

rg -l --null 'github\.com/imdario/mergo' -g '*.go' -g '!vendor/**' \
  | xargs -0 -r sed -i 's#github.com/imdario/mergo#dario.cat/mergo#g'
go get dario.cat/[email protected]
go mod tidy
go test ./...

The rewrite command uses ripgrep and GNU sed/xargs, as available on Linux. On other platforms, use the editor's replace-in-files command over your own .go files, excluding vendored dependencies.

After go mod tidy, github.com/imdario/mergo should disappear from go.mod unless another dependency still imports it. Check the result:

go list -m all
rg 'github\.com/imdario/mergo' go.mod go.sum
rg 'github\.com/imdario/mergo' -g '*.go' -g '!vendor/**'

The old and new module can temporarily coexist if a dependency still uses the old path. Inspect the dependency chain with go mod why -m github.com/imdario/mergo and update that dependency when it supports the vanity path.

Do not add /v1 to the import. Go's major-version suffix convention applies from v2 onward. See Go's module path rules.

Indirect dependency: pin the old path temporarily

If a dependency you cannot immediately change still imports the old path, retain that path and pin it to v0.3.16, the final release declaring github.com/imdario/mergo. Add this replacement to your application's go.mod:

replace github.com/imdario/mergo => github.com/imdario/mergo v0.3.16

Equivalently, from the module root:

go mod edit -replace=github.com/imdario/mergo=github.com/imdario/[email protected]
go mod tidy
go test ./...

This keeps the legacy dependency on the legacy module. It does not upgrade that dependency to v1. Your own code may still use the dario.cat/mergo module at v1.0.2 alongside it. Avoid redirecting the old path to dario.cat/mergo with a replacement: when the graph also uses the vanity module directly, Go can reject one module version being used for two module paths.

A replacement in a library's go.mod does not propagate to applications that depend on that library. Put a temporary replacement in the main application's module, or its active workspace as appropriate. This follows Go's replacement rules.

Once the dependency updates its imports, remove the replacement and tidy again:

go mod edit -dropreplace=github.com/imdario/mergo
go mod tidy
go test ./...

Verify resolution

go list -m dario.cat/[email protected] confirms the selected version. To explicitly check resolution without a module proxy:

GOPROXY=direct go list -m dario.cat/[email protected]

When Go performs direct discovery for the vanity path, it requests the site's ?go-get=1 endpoint and reads its go-import metadata to locate GitHub. The documentation body does not participate in that discovery. See Go's repository discovery rules.

Back to Mergo · FAQ

Source: Mergo at ff8ae09d071c. BSD-3-Clause license. Documentation index · Full documentation.