What Dependency Does Go Use When The A Dependency Is Not Specified In “go.mod” file

Question

I just inherited a Go project that has a go.mod file missing a declared dependency, but the dependency is in the the go.sum file:

...

cloud.google.com/go/storage v?.?.? <- this is the missing entry in go.mod
...

these are the entries in go.sum file:

...
cloud.google.com/go/storage v1.0.0/go.mod h1:<some hash>
cloud.google.com/go/storage v1.5.0/go.mod h1:<some hash>
cloud.google.com/go/storage v1.6.0/go.mod h1:<some hash>
cloud.google.com/go/storage v1.8.0/go.mod h1:<some hash>
cloud.google.com/go/storage v1.10.0 h1:<some hash>
cloud.google.com/go/storage v1.10.0/go.mod h1:<some hash>

...

My questions are:

• Why are there 5 versions in the go.sum file?
• If there are other libraries that depend on these specific versions do all 5 get compiled into the binary?
• Which version of the lib will be linked to my application code since the dependency is not declared?

I tried to find an explanation in the Go documentation but could not locate, any help appreciated.

Answer 1

These dependencies are in all likelihood transitive dependencies, that is dependencies of the packages you depend on (or those that they depend on, etc). The go.sum contains lines for all dependencies of your module, direct or otherwise, in order for builds to be reproducible.

From the Go blog :

In addition to go.mod, the go command maintains a file named go.sum containing the expected cryptographic hashes of the content of specific module versions

...

The go command uses the go.sum file to ensure that future downloads of these modules retrieve the same bits as the first download, to ensure the modules your project depends on do not change unexpectedly, whether for malicious, accidental, or other reasons. Both go.mod and go.sum should be checked into version control.

The version of the package that does get included depends on the go.mod file of the package that you depend on. You may depend on several packages and each may depend on a different version of the dependency.

Whether they end up in your build depends on whether the dependency that includes them is compiled into your binary. An example where that inclusion may not happen are test files/packages, which will usually depend on testing libraries and their dependencies. These are never included in your average go build executable.

You can check the list of packages that will be included in your build like this:

go list -m all

You should just in case run go mod tidy to remove any dependencies that aren't actually needed anymore.