The ... wildcard in arguments to the go command is a package pattern, not a directory pattern. That package pattern matches only packages in the main module — so go mod tidy ./... would mean the same thing as go mod tidy.

And this is pretty easy to do as a bash command or script if you so desire:

for f in $(find . -name go.mod)
do (cd $(dirname $f); go mod tidy)
done

CC @jayconrod @matloob, but I don't think this carries its weight in the go command — especially given how rarely nested modules should be used in the first place.

I don't think we should support this. Go commands generally operate in the context of a specific "main" module. Running go mod tidy across multiple main modules would be very different from anything done today.

I understand it's quite rare. We took this approach after seeing it done in https://github.com/cucumber/godog, as the use case of having multiple modules seems to suit our needs, I seem to remember seeing it in other places too, although can't remember where right now

EDIT: more examples

• https://github.com/FluuxIO/go-xmpp/tree/master/_examples
• https://github.com/elastic/go-elasticsearch/tree/master/_examples/fasthttp

And this is pretty easy to do as a bash command or script if you so desire:

I agree with Bryan. I've been doing something similar, with a bit more care about ignoring huge directories:

go-modules() {
        find . \( -name vendor -o -name '[._].*' -o -name node_modules \) -prune -o -name go.mod -print | sed 's:/go.mod$::'
}

Then, I can just do something like: for m in $(go-modules); do (cd $m && go mod tidy); done

I also found this issue because I was searching on how to manage dependencies used only in _examples. I think instead of supporting recursive go.mod it would be better that go.mod could have separate sections of dependencies for the the library, main programs, examples, and tests. Now everything is cramped in there in the same place.

@mitar that overlaps with existing issues like #26955. If you also think examples should be treated differently, please open a new issue instead.

For now I just made a dummy _ "dependency" import in a test file, so #26955 should probably cover that as well.