Open jerome-laforge opened 8 years ago
Hi Jerome,
Thank you for the detailed issue.
However, there are a couple problems with the fundamental issue itself.
First, the plugin respects what gofmt
does not what goimports
does. This might change in the future as goimports
basically fragmented the ecosystem with this choice. I've asked @bradfitz about this and there doesn't seem to be any way to improve either gofmt
nor change the default behavior of goimports
to match gofmt
.
The second problems is that goimports
groups the imports by its own logic but there are people out there that do the following:
import (
"std/lib/pkg"
"appengine/pkg"
"github.com/myOrg/myPkg"
"github.com/otherOrgs/manyPkg"
)
or this:
import (
"std/lib/pkg"
"appengine/pkg"
"github.com/otherOrgs/manyPkg"
"github.com/myOrg/myPkg"
)
or this:
import (
"std/lib/pkg"
"appengine/pkg"
"github.com/myOrg/myPkg"
"github.com/otherOrgs/manyPkg"
)
or even group packages in other formats. Go documentation / guidelines don't state that the imports must be organized in a certain way and this is left to the user to choose, thus the choices people make :)
Maybe, as a possible solution, what the plugin could do is to group the imports according to "std/lib" "non-std/lib/" rule if the import statement contains an empty line and try to append the import to the similar package path if the path is already present (in which case this could be a valid option).
@zolotov do you think it would make sense to have a project setting to define how the imports are formatted based on user preference from either gofmt
(default / now) or goimports
rules? I'm asking not because of this particular setup @jerome-laforge has, with filewatcher + goimports, but because I've seen projects where the imports should be organized by the goimports
rules and this would cause diffs in the commits if used otherwise.
I like the idea of separating "std/lib" packages from "non-std/lib" packages. This is how most code I've seen is formatted.
@mdwhatcott yup, I think that's the idea behind goimports
. But goimports
is not the default formating tool for Go (unfortunately), gofmt
is.
I've did a very tiny survey and I've found these:
The first 5 most starred repositories in Go on Github are like this:
goimports
goimports
looking likeFrom the first 10, there's 1 using custom stuff, 9 using goimports
.
Yeah, once you've used goimports
, you probably won't go back to plain old gofmt
:)
Why not allow the user to choose which style they prefer (gofmt
or goimports
)?
I suppose I could just stop caring about the order that the plugin inserts the import statements.. :(
Any update on this?
Hello all, First of all, thx for this awesome plugin. I configure the plugin filewatcher to goimported on each save my go giles. Is it possible to add the possibility to add new import at the beginning of the import block instead of at its end. Because that's cause some trouble with goimports that sort the import block.
I try to describle the pb with this example:
initial:
if add
github.com/inconshreveable/log15
via auto import of the idea plugin, I have this :When I save (filewatcher executes goimport on it), I have this:
If I add another package from stdlib (for example strconv) with auto import (as it appends the new import at the end of the block), I have this:
If I save it (and goimported), I have this:
So if autoimport add the new package à the beginning the import block like this
When I save/goimport the file, I have expected result like this:
Regard Jérôme