Use go list instead of go mod graph to build dependency graph

[nscuro]

go mod graph apparently isn't really intended for generating an accurate dependency graph (that is, differentiating between direct and transitive dependencies). This becomes painfully obvious when running that command on modules that have go 1.17 in their go.mod file (golang/go#47648).

The output of go list -deps -json has a .Deps field which we could use to build a dependency graph instead. But go list as of today is still subject to build constraints. That will work for the new app command, but not for mod.

There is however an effort of supporting "unconstrained" use of go list: golang/go#42504

[nscuro]

Oh man, of course! The Module struct has an Indirect field:

Indirect bool // is this module only an indirect dependency of main module?

So we can just prune edges from the main module to its indirect dependencies that way!
I'm not 100% sure that this completely solves the problem, but it certainly is a quick win.

[nscuro]

Alright, so there's still a distinction to be made between direct dependencies and indirect dependencies that have been explicitly declared in go.mod (e.g. to force-update them to a newer version). go mod graph treats explicit, transitive dependencies as edges as well.

[cleaton]

Maybe a flag to toggle removal of indirect dependencies? I think it makes more sense to include all dependencies so the SBOM can cover tests and tools.go.

[nscuro]

@cleaton Transitive dependencies are always included. This issue is more about the dependency graph and the edges within it. As of now, it may be possible that indirect dependencies are considered to be direct. The component inventory is complete in any case.

Regarding test dependencies: This is supported in the mod command.