I think it's highly beneficial to avoid adding flags if possible. gofmt is already pretty opinionated, and people accept that. It has no flags (more or less), which means all projects are formatted the same way. It's better if goimports follows that and leads to more Go codebases following the same formatting style, and save people from having to make a meaningless decision of where to put local imports.

However, this doesn't match the import ordering of some projects which sort local imports last.

A better way to resolve this would be to change those packages to be consistent with what goimports does (easy), or perhaps change goimports if everyone seems to be doing something else (hard; how to confirm this?).

/cc @bradfitz @josharian per owners.

Yeah, I don't really like the idea of a separate flag, but the -local flag has already added some divergence. It'd be nice to agree on what the preferred grouping is:

(a) 2 groups: "standard" and "everything else"
(b) 3 groups: "standard" "non-local" "local"

Related issue is #20818.

Worth noting here that the example in the CodeReviewComments section on imports seems to suggest a three-group pattern: standard library, local imports, then third-party imports. It'd be nice to align that wiki page with the default goimports style.

golang/tools@12a7c31 changed goimports such that groups are combined. e.g.

import (
  "os"

  "github.com/aws/aws-lambda-go/lambdacontext"

  "github.com/elastic/apm-agent-go"
)

becomes

import (
  "os"

  "github.com/aws/aws-lambda-go/lambdacontext"
  "github.com/elastic/apm-agent-go"
)

When using -local, the local packages will be separated as before, such that in the above example, the first grouping would be left intact. This works fine, but then goimports integration with IDEs makes that painful, as IDE-specific configuration will be required to pass in -local. Previously this wasn't any issue, because groups were left alone.

Yeah, I don't really like the idea of a separate flag, but the -local flag has already added some divergence. It'd be nice to agree on what the preferred grouping is:

(a) 2 groups: "standard" and "everything else"
(b) 3 groups: "standard" "non-local" "local"

I'm in favour of one canonical grouping scheme, and my preference is (b). In order for (b) to work, I think we need a way of identifying the local imports without -local, e.g. using a special comment or a config file.

I'm in favour of one canonical grouping scheme, and my preference is (b). In order for (b) to work, I think we need a way of identifying the local imports without -local, e.g. using a special comment or a config file.

I don't like the idea to have a canonical grouping scheme. Because there is no canonical way to name packages and importpaths, there is no way for goimports to be smart enough to do the grouping in a sensible way.

However, a config file might work -- put packages matching certain rules in a certain group -- but such config sounds troublesome and I'd prefer to avoid.

With go modules (go 1.11) One could defer the -local from the go.mod file.

Is there something specific to be done here? I think we're pretty clear that we don't want any more configuration for goimports unless absolutely necessary.

Why not make goimports part of gofmt, removing all configuration? Just sort the imports (and maybe group stdlib and "everything else" separately) and that's it. Why not?

The full functionality of goimports is way too complicated, subtle, and slow to be integrated into gofmt. Sorting and grouping imports I suppose you could make a case for but that doesn't even work right in goimports today, see #20818.

Is there something specific to be done here? I think we're pretty clear that we don't want any more configuration for goimports unless absolutely necessary.

Makes sense to me to avoid any more flags. I think that means the recommendation is to sort local packages in the 3rd group? It would be nice if this was called out and examples (e.g., style guide) reflected that.

A separate unrelated issue, it may be more reasonable to auto-detect -local based on the go.mod. That would allow a user to set their editor to run goimports -w -autolocal (or whatever the flag may be) and it would work automatically for any project. However, that can be a separate issue.

That's https://golang.org/issue/32049, basically.