consider the main module path when grouping imports

[glightfoot]

I know this has been discussed before, but it would be EXTREMELY useful to have an option to disable gofumpt's import sorting. We have an old go codebase that does not have a dot in the module name, and this makes gofumpt unusable for us. While the spec makes sense, changing it is not possible at this time. Additionally, we have extra import grouping rules beyond the local prefix that we would like to not lose.

Gofumpt is the best formatter I've found, and the integration with golangci-lint and autofix would be massively useful if we could just disable import sorting and use our own. It sounds like many people are in the same boat, and adding the option would make gofumpt more useful for everyone.

I'm willing to make the PR to add the option if that helps.

Thanks for making such a wonderful tool!

[mvdan]

While the spec makes sense, changing it is not possible at this time. Additionally, we have extra import grouping rules beyond the local prefix that we would like to not lose.

Can you please explain the background there?

As for the option: sorry, but no; I'm trying really hard to not add more knobs. Just one or two more options and the tool gets significantly harder to maintain and less useful to use, as each project would end up with its own variant.

I really do appreciate the kind words and the struggle, but also, this is a heavily opinionated tool by design. Its format is even stricter than gofmt's. I am fully aware that it may be incompatible with what a minority of codebases want to do, and I think that's fine. I seem to recall that there was also significant pushback against gofmt in the first few years. This is not to say that gofumpt should become the next gofmt, but you also aren't forced to obey its rules :)

And, at least in the case of imports, grouping and sorting imports is useful, so I definitely don't want to outright remove that feature.

[glightfoot]

Sorry, I meant changing our module name is not feasible. From some reading I did in golang issues, it seems like the "all non-stdlib modules should have a domain" wasn't really a rule or anything official, and quite a few older codebases didn't have a domain.

I definitely get wanting to avoid adding knobs and it becoming a maintenance issue, but it does feel like the imports one if different enough to warrant an option to disable that sorting rule, given how many standards and preferences there are around import sorting (see #38). I think this would make adopting gofumpt easier for many people in the same boat.

While the rest of the gofumpt rules are style changes (and all good ones IMO), the imports sorting introduces that unofficial spec that all third party modules should have a domain, which feels different from the rest. Nothing in gofmt/goimports forces modules to be named a certain way, whereas this rule does

[mvdan]

unofficial spec

Just to be clear, it's not an unofficial spec. It is an undocumented assumption which will start being properly documented very soon; see https://go-review.googlesource.com/c/website/+/359594/. I agree it's unfortunate that it was undocumented for a long time, and I appreciate that some projects may struggle with this, but I am not inventing this rule out of thin air :)

That said, perhaps there's a way we could do the right thing without needing a knob. Since gofumpt is already module-aware, it could look up the main module's path; if it is like module foo/bar instead of module foo.com/bar, then it could remember that foo/... is not part of the standard library. Would that be enough for your situation?

[glightfoot]

Oh that's a great idea! Yeah I think that would solve all the issues, thanks. Out of curiosity, how does gofumpt find the module?

[mvdan]

gofumpt/gofmt.go

Line 137 in ba9bdf9

out, err := exec.Command("go", "list", "-m", "-f", "{{.GoVersion}}").Output()

At the moment we only look up the go X.Y information, but also looking up the module path would be rather easy.

[glightfoot]

Yup! I just confirmed that excluding imports beginning with the path from go list -m -f {{.Path}} from import sorting would fix this entirely. Thanks again