Can you give a concrete example of code formatting generated by goimports and then modified by gofmt? Thanks.

Original

package main

import (
	"strings"
	"github.com/gorilla/mux"
	"fmt"
)

func main() {
var _ = mux.NewRouter()
	fmt.Println(strings.ToUpper("Hello, world!"))
}

go fmt (note the alphabetized imports)

package main

import (
	"fmt"
	"github.com/gorilla/mux"
	"strings"
)

func main() {
	var _ = mux.NewRouter()
	fmt.Println(strings.ToUpper("Hello, world!"))
}

goimports (note the imports grouped stdlib, newline, external)

package main

import (
	"fmt"
	"strings"

	"github.com/gorilla/mux"
)

func main() {
	var _ = mux.NewRouter()
	fmt.Println(strings.ToUpper("Hello, world!"))
}

I see. In that case, I believe that this may be a duplicate of #9922.

@rsc was pretty clear in that post that gofmt shouldn’t use goimports rules, and I can respect that. That statement was made almost 5 years ago though, so I wanted to bring it up again under a different light.

I created this issue because there are currently two tools maintained in the Golang org, one pinned with Go releases and another under the x banner.

I respect that not everyone may want their code formatted the way goimports does, however I think maintaining two different tools is wasted effort and confusing to newcomers and veterans alike, especially considering how popular goimports is.

Hence, why I’m proposing merging the two with the implementation being an optional flag

cc @bcmills @heschik

My immediate reaction is that goimports is too complicated and buggy to be tied to the main Go release cycle. The import grouping specifically has known bugs related to comments. But it has been getting more stable over time, so maybe?

I propose that the builtin go fmt sorts imports in the same way as goimports starting with next Go versioned release, and development of goimports ceases.

Perhaps I'm missing something, but goimports does much more than just sorting imports. It also adds missing imports, for example, which is a very complex task with modules.

I'm generally in favor of making the two tools easier to use together, but deprecating goimports entirely wouldn't be as simple as teaching gofmt how to sort imports.

Interesting, I didn’t realize it removed/added imports until just now.

My intent with creating this issue was solely to rectify the formatting discrepancy. Perhaps this issue could be more focused on gofmt then.

Would it be feasible to refactor cmd/gofmt to share code with goimports, similar to how cmd/vet now uses dependencies vendored from golang.org/x/tools/go/analysis?

That would at least make it easier to keep the two in sync.

Would it be feasible to refactor cmd/gofmt to share code with goimports

That's a good point. There's even a comment which says: // Hacked up copy of go/ast/import.go in tools/internal/imports/sortimports.go. There was a fix with import ordering that I had done in gofmt, which had to be replicated again in goimports.

Whatever goimports or gofmt, Please provide an option to format the code in a single or two block, And it doesn't affect the automatic import packages,

Vscode default goimports and two block, goland default gofmt and single block. Our team uses different editors, which creates unnecessary conflicts when merging code.

@hlbbt You can configure goland to use goimports (Editor->Code Style->Go->Imports->Sorting type).

@hlbbt You can configure goland to use goimports (Editor->Code Style->Go->Imports->Sorting type).

I don't like goland, I prefer to use vscode, I want to add options in vscode, not goland

I wrote one, here is the git address

https://github.com/athxx/gfmt

@hlbbt You can configure goland to use goimports (Editor->Code Style->Go->Imports->Sorting type).

I don't like goland, I prefer to use vscode, I want to add options in vscode, not goland

Try this

microsoft/vscode-go#3059 (comment)