My go.mod file looks like this (abbreviated):
go 1.26
require (
github.com/rivo/uniseg v0.4.7 // indirect
github.com/russross/blackfriday/v2 v2.1.0
// ..
)
// Things I maintain
require (
github.com/BurntSushi/toml v1.6.0
zgo.at/runewidth v0.1.0 // indirect
// ..
)
// golang.org/x
require (
golang.org/x/image v0.38.0
golang.org/x/mod v0.33.0 // indirect
// ..
)
I've also had sections like:
// Google cloud and its large dependency tree.
require (
cloud.google.com/go/storage v1.63.0
// ..
)
And:
// External dependencies
require (
github.com/rivo/uniseg v0.4.7 // indirect
github.com/russross/blackfriday/v2 v2.1.0
// ..
)
// Our internal dependencies
require (
github.com/org/repo1 v0.0.0-20250211163505-a3191f81fff2
github.com/org/repo2 v0.0.0-20250310163736-912f462a789f // indirect
// ..
)
And various variants thereof.
I ran gotip mod tidy, and all of that grouping is now lost.
Grouping this is useful as it can hugely clarify your go.mod file in a way that simplistic grouping by direct and indirect dependencies can't. Personally I rarely care if something is a direct or indirect dependency – I care about who maintains it: our team, me, the Go team, or some random internet person.
Unconditionally forcing this in only two groups means you can no longer do this, and makes dependency trees less insightful, rather than more. Anyone reading the go.mod file will get much more of a "wall of text".
I read #56471 and @matloob mentioned "I think we need to figure out if there are any reasons why users would want three sections", but as near as I can tell that never happened and discussion stopped. So, well, this is at least one reason you want more than two sections – I don't know how many people are doing it, but I've used this pattern in a bunch of repos with non-trivial dependency trees. I think it's a good pattern that, IMHO, is quite helpful.
I feel that at the very least it should allow commented sections, which will always be left alone:
// This section has a comment, so we can assume it was created for a reason
// rather than accidentally and "go mod tidy" won't mess with it.
require (
..
)
That would still fix the problem #56471 set out to fix, while retaining the ability to group sections.
CC: @jitsu-net @prattmic @matloob
My go.mod file looks like this (abbreviated):
I've also had sections like:
And:
And various variants thereof.
I ran
gotip mod tidy, and all of that grouping is now lost.Grouping this is useful as it can hugely clarify your go.mod file in a way that simplistic grouping by direct and indirect dependencies can't. Personally I rarely care if something is a direct or indirect dependency – I care about who maintains it: our team, me, the Go team, or some random internet person.
Unconditionally forcing this in only two groups means you can no longer do this, and makes dependency trees less insightful, rather than more. Anyone reading the go.mod file will get much more of a "wall of text".
I read #56471 and @matloob mentioned "I think we need to figure out if there are any reasons why users would want three sections", but as near as I can tell that never happened and discussion stopped. So, well, this is at least one reason you want more than two sections – I don't know how many people are doing it, but I've used this pattern in a bunch of repos with non-trivial dependency trees. I think it's a good pattern that, IMHO, is quite helpful.
I feel that at the very least it should allow commented sections, which will always be left alone:
That would still fix the problem #56471 set out to fix, while retaining the ability to group sections.
CC: @jitsu-net @prattmic @matloob