x/tools/gopls: group imports together for the local module

[gracenoah]

What version of Go are you using (go version)?

$ go version
go version go1.12 linux/amd64

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

not relevant

What did you do?

Saved a file in vs code (configured to use gopls), letting gopls fix imports.

What did you expect to see?

Imports grouped into 3 sections: standard library imports, third party library imports, local module imports

What did you see instead?

Only two sections: standard library imports, all other imports

---

Maybe this is a bike-sheddy style question, but I would like to be able to use gopls but also stick to the old goimports -local x behaviour of splitting local dependencies out.

If it's too controversial, I'd be happy with a flag, but maybe it's simple enough to make this behaviour default, especially now that go modules make it clear what's "local".

[stamblerre]

I think this is ultimately something that we would put behind a config (even if it is on by default). We intend to add different configurations to formatting and imports, but first we will need to fix #30843.

[stamblerre]

@matloob: This is something that we could implement through a suggested fix through go/analysis.

[cespare]

@stamblerre from a cursory glance through the code, it seems like it would be straightforward to plumb through the imports.Options.Env.LocalPrefix config today, whereas #30843 seems like a substantial change.

Would you accept a PR which adds a temporary config option for now? In the future it would be replaced by some other mechanism once #30843 is in.

I ask because the -local option is how we organize all imports at our company, and not having a way to get the same result makes gopls hard to adopt.

[stamblerre]

That sounds like a reasonable temporary measure. I'll leave the final decision to @suzmue though, since she has much more expertise with goimports.

[suzmue]

That sounds good to me as well.

[smyrman]

Is it relevant to utilize the path in go module to determine the local path?

[sushicw]

I'm running into this pain point as well.

@cespare Are you still working on a PR to add a config flag for this?

[cespare]

@sushicw Not actively. It's on my to-do list. If you'd like to do it, go ahead.

I expect I'll get to this in the next 1-2 months.

[gopherbot]

Change https://golang.org/cl/204820 mentions this issue: internal/lsp: add LocalPrefix configuration

[stamblerre]

The change above adds a LocalPrefix configuration, but I do think it would be worth considering a default value that uses the name of the main module. Let's start with this configuration though, and then consider the further improvements.

[zikaeroh]

I went to try this out, but couldn't get it to work (even added some logging where the ProcessEnv gets created to make sure it was plumbing it down). Turns out that the VS Code Go extension is the one doing the formatting, and not gopls. Is there some trick I've missed to make use of gopls as the formatter rather than an external tool?

[stamblerre]

@zikaeroh: What are your VSCode settings (Ctrl + Shift + P -> Preferences: Open Settings (JSON))? As long as you haven't explicitly disabled formatting in go.experimentalLanguageServerFlags, I don't see why it wouldn't go through gopls.

[zikaeroh]

Ah, that's it. I set the format flag to false, probably because format-on-save wasn't behaving the way I wanted the first time I used gopls a while ago. I'll retest when I get a chance later today.

[alexanderbez]

Can someone share the VSCode settings needed to get this to work, please?

Here is what I currently have:

    "go.useLanguageServer": true,
    "go.languageServerExperimentalFeatures": {
        "documentLink": false,
        "incrementalSync": true,
    },
    "gopls": {
        "usePlaceholders": false,
        "completionDocumentation": true,
    },
    "[go]": {
        "editor.codeActionsOnSave": {
            "source.organizeImports": true,
        },
        "editor.codeActionsOnSaveTimeout": 3000,
        // "editor.defaultFormatter": "ms-vscode.Go",
        "editor.formatOnSave": true,
        "editor.snippetSuggestions": "none",
    },
    "editor.formatOnSave": true

I would like to use the new LocalPrefix config/flag.

[stamblerre]

You will need to add "local": "your module path" to the "gopls" settings block.

[zikaeroh]

Had some time so went to test it out... I remember why I disabled gopls's formatting, it's pretty broken for me. 🙁

I'll have to file a new bug for it, but doing something like moving some imports around and saving reformats my imports very wrong, with some disappearing and sometimes even quotes getting misplaced. That, and the local option doesn't appear to have done it for me. I'll try to do better testing tonight, but I foresee staying with goimports externally as that's been working very well up to this point.

EDIT: I got it to work, but only if I use "organize imports". Personally, I want the old goimports behavior of "save the file and everything just works out", so I hope the gopls scheme isn't separate actions for everything I have to remember to run...

[alexanderbez]

You will need to add "local": "your module path" to the "gopls" settings block.

I get unexpected config local when doing this.

gopls version:

golang.org/x/tools/gopls v0.1.7
    golang.org/x/tools/[email protected] h1:YwKf8t9h69++qCtVmc2q6fVuetFXmmu9LKoPMYLZid4=

[stamblerre]

@zikaeroh: Can you file a new issue with a repro for the case where gopls formatting messes things up? All you should need are the format and code action on save hooks described here: https://github.com/golang/tools/blob/master/gopls/doc/vscode.md#vscode.

@alexanderbez: Sorry, forgot to mention that you will also need to install the latest pre-release of gopls - run this command from a temporary directory: go get golang.org/x/tools/[email protected].

[zikaeroh]

Opened #35388. I do have all of the recommended options set including the on-save options and an extended timeout, but no dice. goimports works great. :P

[alexanderbez]

got it working, but the importing is definitely not right. Probably what @zikaeroh is alluding to. It's not even grouping stdlib imports.

[stamblerre]

@alexanderbez: Does it work if you remove an import? goimports won't necessarily move things around unless things are changed (see #20818).

[alexanderbez]

goimports works perfectly. But when I simply save (with the new local config) I get:

import (
	"fmt"
	"github.com/cosmos/cosmos-sdk/codec"
	sdk "github.com/cosmos/cosmos-sdk/types"
	abci "github.com/tendermint/tendermint/abci/types"
	"os"
	"sort"
	"strings"
	"syscall"
)

what I expect:

import (
	"fmt"
	"os"
	"sort"
	"strings"
	"syscall"

	"github.com/cosmos/cosmos-sdk/codec"

	sdk "github.com/cosmos/cosmos-sdk/types"
	abci "github.com/tendermint/tendermint/abci/types"
)

assuming "github.com/cosmos/cosmos-sdk" is my local prefix.

[stamblerre]

What is the content of the original file?

[myitcv]

@alexanderbez I think the issue you're seeing falls under the banner of "working as expected".

I ran into exactly the same difference in behaviour with existing imports between gopls and goimports. @heschik replied on Slack:

Okay, goimports' behavior for groups is weirder than I realized. I think the only case you can actually expect it to work in is when it's adding an import.

I don't understand why goimports on the command line would behave differently but I don't think it makes sense to worry about it separately from that bug.

"That bug" is a reference to #20818

What's unclear to me is why goimports behaves in one way and gopls in another; this lack of consistency is I think going to be a source of confusion for users of gopls who are expecting https://go-review.googlesource.com/c/tools/+/204820/ to behave like goimports -local.

[alexanderbez]

I'm unsure on how to proceed with the gopls config. I would prefer to avoid having to call goimports from the CLI manually every time I commit.

[myitcv]

Actually I'm going to correct the comment I made in #32049 (comment)

At least with gopls and x/tools 95cb2a1 (we currently can't move beyond 95cb2a1 because otherwise we start tripping over the mistmatched versions problem described in #35114) things do work if the import already exists i.e. imports are regrouped.

This is demonstrated in the two tests we are adding as part of govim/govim#571

So my best guess would be that any issues we're seeing here are related to version problems that fall under the banner of #35114.

Again, fixing those version problems will help us to see more clearly whether there other issues later.

[stamblerre]

I'm going to go ahead and close this issue, since the local flag has now been added. Automatic detection of the local module can be tracked through #31999.

@alexanderbez and anyone else who is having trouble with imports through gopls or the LocalPrefix configuration, please open a new issue, and we will help investigate.

[cespare]

@stamblerre what is the gopls documentation page where I could learn about the "local" option you referred to in #32049 (comment)? This issue (and the source code) are the only references I've found.

Edit: I think that the page I'm looking for is the Settings wiki page, so maybe the problem is just that that documentation page is missing a mention of this option.

[stamblerre]

@cespare: You're right--it is missing from documentation. Just mailed https://golang.org/cl/224117 to add it.