Unfriendly behavior for new users when adding a module

[aathan]

What version of Go, VS Code & VS Code Go extension are you using?

Version Information

• Run go version to get version of Go from the VS Code integrated terminal.

  • go version go1.19.3 linux/amd64

• Run gopls -v version to get version of Gopls from the VS Code integrated terminal.

  • golang.org/x/tools/[email protected] h1:Q0cfPbEG1WVfgxcRZ9uKTA6/ckIRNXx6Ym7KgT/VFE4=

• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders.

  • 1.80.2
    2ccd690cbff1569e4a83d7c43d45101f817401dc
    x64

• Check your installed extensions to get the version of the VS Code Go extension

  • v0.39.1

Share the Go related settings you have added/edited

Describe the bug

If you want to add a completely new module which has never been used in a project, you must go get... Meanwhile, that command seems to inspect the code to determine what's referenced. If you try and add a reference to the module, you "can't" because every time you add the import and hit save, the reformatter nukes the import because nothing uses it. If you do the go get before you add the import, the module ends up //indirect and in go.sum it's commented out.

I ended up having to break out to emacs, add the import, then go get & go mod tidy/vendor/etc before things started working correctly.

Steps to reproduce the behavior:

See above.

Screenshots or recordings

If applicable, add screenshots or recordings to help explain your problem.

[findleyr]

Thanks @aathan. This is not the first time this has come up, but it is a hard problem to solve as many users (myself included) do not ever type imports manually, preferring to let goimports manage import entirely. Of course, in some codebases goimports doesn't always compute the correct import, making this model less friendly.

There is more discussion of this on golang/go#54362. While discussing your issue last week, we decided to prioritize this for an upcoming milestone: we will add a goimports mode that does not delete unused imports, along with a quick fix that can be invoked to delete them as a separate step. At least initially, this won't be the default, because we have many users who are used to the current behavior.

Therefore, I will close this as a dupe of golang/go#54362.