x/tools/gopls: add a setting to control removal of unused imports, and a quickfix

[findleyr]

We see feedback in survey results that users don't want unused imports to be removed by the organizeImports code action. I myself sometimes get annoyed by this behavior: it can be frustrating to manually type out an import path, save, and have the import disappear.

Surprisingly, I don't think we have an open (or closed) request for this feature, unless my search failed me.

I think we should consider a configuration option removeUnusedImports to control the removal of unused imports, and the default should probably be to not to remove unused imports EDIT: I take that back, the default behavior should not change.

[muirdm]

When do you need to manually type an import?

This would mean after removing the final use of a package and saving, the import wouldn’t be removed automatically by default? When would the unused imports be cleaned up?

[findleyr]

When do you need to manually type an import?

I sometimes do this to improve completion results, actually, which may suggest an alternative solution.

This would mean after removing the final use of a package and saving, the import wouldn’t be removed automatically by default? When would the unused imports be cleaned up?

Err yes these are good points. I filed this issue (rather nearsightedly) based on consistent feedback we see that this is a point of confusion / frustration. But of course the alternative has significant downsides, which you point out, thanks. I think we need more research into whether we can mitigate this pain point by other means, such as improving unimported completion. I've removed the conviction in the original post, and removed this from the milestone.

[skelouse]

@findleyr When trying to improve autocomplete rather than typing it into the imports type it into go get -u github.com/..... This will add it to the auto-import mechanism.

[adonovan]

An unused import generates a compile error, so we shouldn't leave them in as a convenience. If better completions is the motivation for this feature, we should improve the completion algorithm so that it generates candidates from unimported packages.

The only other case I can think of for wanting this is when temporarily commenting out the last use of an imported package, but usually goimports correctly restores the import when the code us uncommented. In any case, if that's not sufficient, I think the fix should be in goimports, not in suppressing the removal in the first place.

[hyangah]

VS Code users who'd rather like to fix this compilation error manually can turn it off from the settings:

    "[go]": {
        "editor.codeActionsOnSave": {
            "source.organizeImports": false
        }
    },

And explicitly invoke "Organize Import command" manually from the Command Palette when you think your code is ready closer to buildable state.

As you can see, there is a key binding already too.

(Caveat: it will not automatically add imports either)

[findleyr]

We discussed this again, as it consistently comes up, particularly from new users.

I think it would be OK to add a new (non-default) mode to gopls' goimports integration that doesn't delete imports. Particularly with a quickfix to clean up the unused import error, I can see an alternate workflow that works better for some users, where cleaning up unused imports is performed as a separate step.

I personally would continue to use the default behavior, but don't have a problem with supporting this alternate behavior.

[muirdm]

Is the main use case manually typing import statements and then losing them on save? Maybe we could detect that and automatically suppress the goimports deletion.

If this feature is mostly requested by new users, the above approach is nice since it gives those users a path to getting used to the full power of goimports.

[findleyr]

Yes, we regularly hear feedback from users who are frustrated that after typing an import path and saving, the import is deleted. I personally am used to never typing an import path, but understand that this may not be the workflow for users coming from a different language, or who are working in codebases where goimports doesn't work as well -- our codebases tend to have very few dependencies, and so goimports generally does a good job picking the right one.

[aathan]

Just to provide a little more color re golang/vscode-go#2930: This may be due to being unfamiliar with some of the tooling features, but in my experience so far, it is not possible to "never" type an import path (can you elaborate on how this is achieved?) ... e.g., if an import is for a third party module, e.g., one provided from a git repo etc, I'm not sure I see how that import could possibly be inserted for me -- at least not until I've done a "go get" or otherwise manually having added it to the project somehow. Then, the issue is that "go get" (again, I may be showing my noob-iness here), won't do the right thing if there is no pre-existing import reference to the project.

That's where there's a frustrating loop that occurs: You try to add the import, the import gets deleted by reformat-on-save, you can't do the proper "go get" etc.

I guess a workflow would be to add the import and use it somewhere in the file before saving, but you may be relying on symbol completion etc to really use it properly vs entering some dummy use.

Maybe another approach would be to add features to the reformatter such that if a module is imported and not used, but it also doesn't appear in go.mod etc properly, then it is not removed, and instead a comment is added //unused: not in go.mod ?

EDIT: btw, in my setup, the format tool is set to "default" so I guess it's gopls that's doing the import reformatting on save.

EDIT2: After re-reading the rest of the comments here, I wanted to add that maybe something strange or again, related to my noob-iness, was occurring. See the issue linked at the top of this comment for a hopefully clear-enough description based on my vague understanding of what was going on.

EDIT3: Another idea which may obviate the need for a toggle to disable goimports import cleanup: Provide an action which adds an import explicitly, marking it as I suggested above with a comment. The comment can then automatically be removed once the import is in fact used in the code. If the comment format is simple enough, users can also add the import manually without invoking the command.

[jichanbachan]

My input may not be particularly useful as I am very new to Go, but after being slightly frustrated by having my imports deleted before I could use them, I attempted to see if I could turn it off. I understand now that unused imports are treated as compile errors, but it was a bit unfortunate that my only options as a newbie were to get used to it or turn it off entirely. For me, I run into this when I am typing out an import statement and immediately hitting save before using anything from the package.

I would like to suggest an option to simply have the unused import be commented out, so that it avoids the compile error without removing all traces of what was there.

[aathan]

note that there is an option to save without formatting

[data-pata]

note that there is an option to save without formatting

@aathan, Can you elaborate?

"editor.formatOnSave": false doesn't change the behavior of gopls with regard to organizing imports. See above.
(I'm assuming that you refer to VS Code settings).