Consider the following program
package main
import (
"github.com/spf13/viper"
"github.com/davecgh/go-spew/spew"
)
func main() {
spew.Dump(viper.New())
}
with the following go.mod file:
module example.com/test
go 1.22
require (
github.com/davecgh/go-spew v1.1.1
github.com/spf13/viper v1.18.2
)
require (
github.com/fsnotify/fsnotify v1.7.0 // indirect
github.com/hashicorp/hcl v1.0.0 // indirect
github.com/magiconair/properties v1.8.7 // indirect
github.com/mitchellh/mapstructure v1.5.0 // indirect
github.com/pelletier/go-toml/v2 v2.1.0 // indirect
github.com/sagikazarmark/locafero v0.4.0 // indirect
github.com/sagikazarmark/slog-shim v0.1.0 // indirect
github.com/sourcegraph/conc v0.3.0 // indirect
github.com/spf13/afero v1.11.0 // indirect
github.com/spf13/cast v1.6.0 // indirect
github.com/spf13/pflag v1.0.5 // indirect
github.com/subosito/gotenv v1.6.0 // indirect
go.uber.org/atomic v1.9.0 // indirect
go.uber.org/multierr v1.9.0 // indirect
golang.org/x/exp v0.0.0-20230905200255-921286631fa9 // indirect
golang.org/x/sys v0.15.0 // indirect
golang.org/x/text v0.14.0 // indirect
gopkg.in/ini.v1 v1.67.0 // indirect
gopkg.in/yaml.v3 v3.0.1 // indirect
)
Running go mod tidy on this go.mod file will actually replace github.com/davecgh/go-spew v1.1.1 with v1.1.2-0.20180830191138-d8f796af33cc. I want to know what transitive dependency is (wrongly, IMO) declaring a dependency on v1.1.2-0.20180830191138-d8f796af33cc.
go mod graph | grep [email protected] gives
example.com/test github.com/davecgh/[email protected]
github.com/spf13/[email protected] github.com/davecgh/[email protected]
From this, I can see that it's coming in via github.com/spf13/[email protected], but spf13/viper doesn't actually have a direct dependency on v1.1.2-0.20180830191138-d8f796af33cc. Cloning the spf13/viper repo and running go mod graph | grep [email protected] gives
github.com/spf13/viper github.com/davecgh/[email protected]
github.com/hashicorp/consul/[email protected] github.com/davecgh/[email protected]
But it turns out hashicorp/consul/api doesn't have a direct dependency on v1.1.2-0.20180830191138-d8f796af33cc either.
I could continue this process and presumably end up finding the transitive dependency whose go.mod does have a direct dependency on v1.1.2-0.20180830191138-d8f796af33cc, but is this how go mod graph is supposed to work, or am I missing something? Is there a simple way to get the full dependency graph?