How to Resolve Conflicting Go Module Dependencies When Top-Level and Sub-Module Are Imported as Different Versions?

Resolving Conflicting Go Module Dependencies when Top-Level Module and Sub-Module Are Imported as Different Versions

Go module dependencies can occasionally lead to conflicts when a top-level module and one of its sub-modules are separately imported as different versions. Let's explore this issue and find a solution.

Problem Overview

When you have two dependencies in a project, as shown in the go.mod file below, the go mod download command may result in the download of different versions of a shared sub-module.

module github.com/test-org/test-repo

go 1.12

require (
    github.com/foo/bar v1.0.0
    github.com/raz/mataz v1.0.0
)

This can lead to ambiguous import errors when importing the sub-module in your code, as the go tooling is unsure which version to choose.

Solution

The issue arises when one of the dependencies references a pre-go-modules version of the sub-module. This black box import of the entire repository conflicts with the module reference to the sub-module.

To resolve this conflict, you can force references to the shared dependency to use go-module-enabled versions. Add the following line to your go.mod file:

replace (
    github.com/shared/dependency => github.com/shared/dependency v1.2.0
)

Ensure that the version specified (v1.2.0 in this example) is go-module-enabled (has a go.mod file).

This solution works because it ensures that all references to the shared dependency use module versions, eliminating the black box import conflict that led to the ambiguous import error.

The above is the detailed content of How to Resolve Conflicting Go Module Dependencies When Top-Level and Sub-Module Are Imported as Different Versions?. For more information, please follow other related articles on the PHP Chinese website!