There have been a number of requests for a test dependencies section in go.mod. These requests actually don't make sense with the way that go.mod works, because it's really just a list of rules to follow for resolving dependencies, not a list of dependencies. The actual list of dependencies is per-package, not per-module, and is determined by the actual import statements in the code itself. The go tool, however, does add some extra information to the go.mod file in the form of an // indirect comment after dependencies that are only depended on by a dependency.
I propose adding an alternate comment flag, test, to indicate that a dependency is only required by tests. Along with this, add an indication of this to the Module struct used for formatting go list -m output.
Comment From: komuw
I tried implementing this sometime back as a cli at; https://github.com/komuw/ote (has bugs).
I would be in favor of the go tool adding // test comment.
Comment From: cndoit18
any update?
Comment From: dfawley
I'm curious about the state of things here, given this is 3.5 years old now.
Do Go users care about auditing transitive dependencies via go.mod entries? As a maintainer of gRPC, we have had related issues reported to us in the past, but I'm not sure if the status quo has changed since then.
Should we attempt to minimize the list of dependencies in go.mod even for testing-only or optional packages, by utilizing submodules? Or should we just use whatever we want in our tests and not worry about the implications in go.mod?
This feature request would help prevent those worries, but maybe it's unnecessary if the ecosystem no longer is concerned about go.mod contents and instead knows to focus on go list.
Comment From: ianlancetaylor
CC @matloob @samthanawalla
Comment From: matloob
I'm split on this. I think it would definitely be helpful to see which dependencies are test dependencies (especially when doing code review of a go.mod file). But I wonder if it would be better to surface this information in other tools?
I definitely don't think we should use submodules to minimize testing only dependencies. Module pruning treats tests different than other dependencies, so a test dependency in a go.mod isn't going to affect other modules that depend on your module the way a non-test dependency would.
Comment From: komuw
But I wonder if it would be better to surface this information in other tools?
I created https://github.com/komuw/ote for this. Here's an example mod file rendered using that tool; https://github.com/komuw/ong/blob/main/go.mod
YMMV
Comment From: borissmidt
Nie that we have tool dependencies it might make sense to have test dependencies. Since it eould be quite unfortunate that you include a new module and suddenly one of your test dependency has a breaking change.
For example kubernetes controllers often use gomega and ginko. Which you dont even want to download if you dont use them when you include there api.
Comment From: matloob
@borissmidt Is the case you're mentioning that a tool only module might add a test dependency that's broken to your module?
Comment From: borissmidt
What i meant is if there is a tool dependency now as a seperate dependency type. It might be usefull to have a test dependency type
Comment From: seankhliao
a tool dependency isn't a separate dependency type. tool packages are recorded in go.mod, the modules that contain the packages are still indirect dependencies in the module graph.
Comment From: sanan-go
I wonder if it would also allow to reduce the number of indirect dependencies (by ignoring indirect test dependencies)