Group imports as std, external, internal

[Southclaws]

A convention I and coworkers often follow is a further separation of imports by relationship to the current project. So anything from the app/library itself is grouped separately so you can easily see all the external dependencies without them getting mixed with internal dependencies.

import (
	"bytes"
	"encoding/json"
	"fmt"
	"io"
	"net/http"

	"github.com/go-chi/chi"
	"github.com/pkg/errors"
	"github.com/lib/pq"

	"github.com/our-company-org/our-project/stuff"
	"github.com/our-company-org/our-project/internal/other-stuff"
	"github.com/our-company-org/our-project/internal/secret/generics"
)

It would be neat for gofumpt to read the current package from go.mod — which in the example above, would be github.com/our-company-org/our-project — then group any package with that prefix at the bottom of the import block.

Maybe this is too specific though, I'm not sure if anyone else does this.

[mvdan]

We already do part of this. We force all standard library imports to be in the first group.

I thought about extending the logic to also enforce that the last group contain all the imports from within the same module. However, I think that would be too risky, for two reasons:

1. The tool is not module-aware at all, at the moment. Note that you can run gofumpt foo.go, and that file may not belong to any module. There are also other fun problems, like what would happen if one runs cd module1; gofumpt ../module2/foo.go. Would this use module1 or module2? Either way, this would make the tool more complex, and slower, as we'd have to run something like go list -m -json.

2. I'm not convinced that everyone follows this pattern. It certainly is common, and enforcing it could be good, but I also imagine it's going to make some users upset. I only want to enforce what 99% of users already do, and is considered as part of "idiomatic go" formatting.

[Southclaws]

Makes sense, I didn't think of the complexities of inside/outside modules and forgot about the lack of module-awareness!

[mvdan]

The heuristic here was a bit lax; I've made it a bit more aggressive. See the commit pushed to master just above.

[dnwe]

@mvdan FYI I did notice that there is also https://github.com/daixiang0/gci in this space now

[mvdan]

Thanks! This discussion has now moved to #38 for the most part, which is open. I've left a couple of design proposals near the end of the thread.