Why: goimports groups imports by stdlib/non-stdlib, gofmt doesn't

[Antoine Grondin]

When formatting code with `cmd/gofmt`, the imports are sorted. However no distinction is made about stdlib imports and other imports.

However, formatting code with `cmd/goimports` does separate the two in different groups.

My instinct is that both should produce the same output, since both are part of the Go project.  Right now, the output of both differs and it means

that everytime a teamate uses `goimports` after I used `gofmt` on the same file, the two files will have extra lines in the diff because of those sorts.

[Ian Lance Taylor]

gofmt follows a simple rule, which is to sort each group of imports,
where different groups are separated by a blank line.

goimports also follows a simple rule, which is to put stdlib imports
in one group and non-stdlib imports in a different group.

Both rules are simple, and both are compatible, but they are
different. There is no special reason for gofmt to implement
goimports rule. gofmt doesn't tend to mess with the way you have
chosen to group your code.

Ian

[Antoine Grondin]

I'm asking because `goimports` users now expect me to manually separate stdlib imports from non-stdlib ones for conformity, and it makes me despair since I thought `gofmt` was supposed to silence all petty style questions like this. =( makes me really a sad panda.

It's suggested that I start using `goimports` to achieve the same import grouping results, which I dislike because I prefer managing imports myself (goimports something imports the wrong package).

What I really wish was that both would sort and group imports the same way, so that users of `goimports` don't end up having code that's not formatted the same than users of `gofmt`.

[Antoine Grondin]

*goimports sometimes

[Daniel Skinner]

The two don't actually interfere with each other do they? gofmt doesn't remove line breaks in imports, right? That should make both co-exist mostly ok but when someone with goimports checks in code, the import structure would change a little. When someone with gofmt edits the code, the imports wouldn't change.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Antoine Grondin]

Exactly, but there is still that change when its first `goimport`'d, and then the expectation that I should use `goimport` to avoid those changes.  I'd be fine with using `goimport` if all it was doing was grouping the imports, but obviously that's not all it does.

[Daniel Skinner]

yes well, using goimports is a bit of a rabbit hole in that (what I'd consider a very) minor case then.

Personally, I prefer to organize imports by domain/major-package anyway.

[Kallen Ding]

I perfer to groups imports by stdlib and non-stdlib ! 

在 2014年10月3日星期五 UTC+8上午3:28:32，Antoine Grondin写道：

[Tong Sun]

On Monday, January 8, 2018 at 4:32:38 AM UTC-5, Kallen Ding wrote:

I perfer to groups imports by stdlib and non-stdlib ! 

Me too. 

When it was not support previously, I deliberately using two imports to separate them.