mirror of
https://github.com/golang/go.git
synced 2024-09-21 10:28:27 +00:00
minor tweaks to recent material
parent
584c4bb6fd
commit
bfa9eca33c
@ -878,7 +878,7 @@ Please see the question "Won't minimal version selection keep developers from ge
|
||||
|
||||
2. The second step usually should be to check `go list -m all` to see the list of actual versions selected for your build. `go list -m all` shows you the final selected versions, including for indirect dependencies and after resolving versions for any shared dependencies. It also shows the outcome of any `replace` and `exclude` directives.
|
||||
|
||||
3. A good next step can be to examine the output of `go mod graph` or `go mod graph | grep <module-of-interest>`. `go mod graph` prints the module requirement graph (including taking into account replacements). Each line in the output has two fields: the first column is a consuming module, and the second column is one of that module's requirements (including the version required by that consuming module). This can be a quick way to see which modules are requiring a particular dependency, including when you different versions required for shared dependencies.
|
||||
3. A good next step can be to examine the output of `go mod graph` or `go mod graph | grep <module-of-interest>`. `go mod graph` prints the module requirement graph (including taking into account replacements). Each line in the output has two fields: the first column is a consuming module, and the second column is one of that module's requirements (including the version required by that consuming module). This can be a quick way to see which modules are requiring a particular dependency, including when your build has different version numbers required for shared dependencies.
|
||||
|
||||
`go mod why -m <module>` can also be useful here, although it is typically more useful for seeing why a dependency is included at all (rather than why a dependency ends up with a particular version).
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user