x/tools/cmd/goimports: Allow "-local" imports to be sorted in between standard library and third party imports

[prashantv]

goimports supports a -local flag to identify local imports, which are currently sorted after 3rd party import groups. However, this doesn't match the import ordering of some projects which sort local imports last. E.g.,

• gVisor
• some parts of go-cloud

Should goimports have flags to control the import group ordering, or should local packages always be imported last?

[dmitshur]

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.

[prashantv]

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"

[dmitshur]

Related issue is #20818.

[akshayjshah]

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.

[axw]

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.

[ashi009]

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.

[smyrman]

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

[heschi]

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.

[ash2k]

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?

[heschi]

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.