Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
prashantv opened this issue Sep 14, 2018 · 7 comments

Comments

@prashantv
Copy link
Contributor

commented Sep 14, 2018

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.,

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

@gopherbot gopherbot added this to the Unreleased milestone Sep 14, 2018

@dmitshur

This comment has been minimized.

Copy link
Member

commented Sep 14, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Sep 14, 2018

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

This comment has been minimized.

Copy link
Member

commented Sep 17, 2018

Related issue is #20818.

@akshayjshah

This comment has been minimized.

Copy link

commented Sep 18, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Oct 15, 2018

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

This comment has been minimized.

Copy link

commented Oct 24, 2018

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

This comment has been minimized.

Copy link

commented Dec 5, 2018

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

@gopherbot gopherbot added the Tools label Sep 12, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.