go list -json is very useful, because it makes its output very easy to consume by other programs. Its companion, go list -f, is almost equally as useful for similar cases, such as when one needs just one field, or when one is calling the Go tool from a shell script, where JSON decoding isn't as straightforward.

So, for instance, I can obtain the current package's import path via just go list -f {{.ImportPath}} rather than reaching for an external tool like go list -json | jq -r .ImportPath.

I argue that a similar situation applies to go mod edit -json; it's a great way to obtain the data contained by go.mod files without needing to use a parser that understands its syntax. However, we lack a go mod edit -f, so if I want to obtain just one field like {{.Go}}, I have to reach for a JSON parser.

I think it would be relatively straightforward to add go mod edit -f, and it would make the command more consistent with go list -f.

One potential argument against this proposed flag addition is that we already have other cmd/go commands that have a -json flag, but no -f flag. One by one, and excluding go mod edit, these are:

• go work edit: arguably the same case as go mod edit, and should be changed as well
• go test -json: it prints a newline-separated stream of JSON objects, and it tends to print a lot more output, so a proper program with a JSON parser is a reasonable requirement
• go env -json: it's already easy to get a single value without JSON encoding via go env NAME, so go env -f {{.NAME}} feels redundant