BrokenImport

[unusualevent]

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.20.7 linux/amd64
• Run gopls -v version to get version of Gopls from the VS Code integrated terminal.
  • golang.org/x/tools/gopls v0.13.1 (among other lines)
• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders.
  • 1.81.0 6445d93c81ebe42c4cbd7a60712e0b17d9463e97
• Check your installed extensions to get the version of the VS Code Go extension
  • v0.39.1
• Run Ctrl+Shift+P (Cmd+Shift+P on Mac OS) > Go: Locate Configured Go Tools command.
  • toolsGopath is blank, after that it lists most of the paths for gotests, dlv, etc as being in ~/go/bin/, it's a long output how much of it do you want?

Share the Go related settings you have added/edited

Run Preferences: Open Settings (JSON) command to open your settings.json file.
Share all the settings with the go. or ["go"] or gopls prefixes.

^ the above instruction is imprecise, there's user settings, workspace settings, folder settings (and default settings)

    "go.toolsManagement.autoUpdate": true,
    "go.lintTool": "revive" // I've tried a bunch of these, so I was toggling through each one frustrated because none of em showed the bug I was after.

Describe the bug

Possibly related to the "if there are multiple nested gomodules in the workspace folder, gopls doesn't work" thing.

what happens: vscode shows github.com/go-chi/chi doesn't exist, but go build works just fine.

what should happen: vscode's go detection should work the same (or better than) the in-terminal detection.

Steps to reproduce the behavior:

1. create a git repo outside ~/go/src. for example, ~/git/awesome/
2. create several subfolders, ./frontend, ./wiki, ./server, ./client, ./server-rewrite
3. make a go module in ./server and ./server-rewrite (this makes me suspect an issue with gopls is related)
4. add some code with imports
5. go get
6. go build
7. vscode thinks they don't exist

for example:

// router.go
import (
	"encoding/json"
	"net/http"
	"time"

	"github.com/go-chi/chi"
	"github.com/go-chi/chi/middleware"
	"github.com/go-chi/cors"
)

// CoolRouter returns the main router
func CoolRouter(OriginAddr string) http.Handler {
	r := chi.NewRouter()
        // add a bunch of subrouters, etc, etc,
        return r
}

Screenshots or recordings

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

possibly related??

golang/go#57979 ("Confusingly, if there is only one module in a nested directory, gopls will work. But if there are two modules, gopls won’t work.")
#2124
#2761
#2607

does that mean I'd have to open ~/git/awesome/server and ~/git/awesome/server-rewrite as separate folders within the workspace?
That has (at least two) downsides:

1. can't copy/paste files within different folders of a workspace
2. git detection is spotty if you don't open the root ~/git/awesome/(.git) folder (sometimes non-existent in-ide git diff highlighting)
3. view of the full git repo isn't plain/intuitive if opening subdirectories instead of the larger whole

[unusualevent]

renaming all the other go.mod / go.sum files to go.mod.backup doesn't make the issue go away... so there's that.

[jamalc]

Work is in progress golang/go#57979. In the meantime, do any of the wiki suggestions on working with multiple modules resolve your issue?

[unusualevent]

go workspaces seems to work (though I have no idea why the renamed subfolder still fails, if it's only one subfolder with a go module, so the ongoing work in 57979 might not fix this specific bug)

edit: blog theme (hugo) had a go.mod in it, so that's another spot where go.mod's can randomly show up...

but renaming everything to go.mod.backup and go.sum.backup except one ~/git/awesome/server/go.mod still fails - which is weird because recreating the same thing from scratch doesn't have that issue:

./helloworld/ // open in editor
./helloworld/example (intact routes.go, main.go, go.mod, go.sum)
./helloworld/example2 (intact routes.go, main.go, go.mod.backup, go.sum.backup)

the from scratch example seems to work like how the issue with gopls describes (one and only one subfolder with a valid go.mod)

[findleyr]

@unusualevent sorry, I'm not sure I understand. In your example, I would expect ./helloworld/example to work, but not ./helloworld/example2. Is that what you observed?

[unusualevent]

@findleyr having ./helloworld/example as a subfolder in a larger repo (helloworld) as a go module does not work.

[hyangah]

When working with multiple modules, please create a go.work file in the top level directory where you open your vscode from (./helloworld in your example). When you rename a directory, you will also need to update the directory path written in go.work. If you remove go.mod from a directory, make sure the files under the directory still belong to some module (go.mod) and that go.mod file captures all the dependencies.

If that doesn't work, please share the full directory structure you are trying to work in and where you have go.work and go.mod files, and their contents. Thank you for the repro case description in the original report, but I think it's missing exactly where go.work/go.mod/go.sum files are. Can you please provide the details?

If you need more info about go workspace, I hope tutorials like https://go.dev/doc/tutorial/workspaces or blog post (https://go.dev/blog/get-familiar-with-workspaces) are helpful.

[xrstf]

I think I am affected by the same issue. All of a sudden, in all my Go projects, vscode shows all non-stdlib imports as BrokenImports, yet all my projects compile just fine. I do not have a single go.work file anywhere on my computer, just a bunch of normal Go projects that all have a go.mod/go.sum.

I had no issues up until maybe a week ago.

It seems I have to suddenly git clone every. single. package. that I depend on, i.e. $GOPATH/pkg is not used anymore, I seem to need the plain text source files in $GOPATH/src.

EDIT: After digging more, it seems that this issue begins to happen when I add a folder to VSCode that contains multiple Go modules. Normally my Go projects have exactly 1 go.mod in them, in the root directory. But I also have one special Git repository that contains sub folders with go modules.

VSCode always had issues with go.mod files in sub folders, which was a documented known issue. But the issue never bled into other Go projects in the same VSCode workspace. Now all of a sudden, the moment I add my multi-project repo to VSCode, all other Go projects are affected.

To me this feels like a hefty regression in either VSCode or gopls.

[findleyr]

@xrstf this does indeed sound like a regression. gopls@v0.15.0 was in fact designed to simplify working in multi-module workspaces (and fix several bugs). What you're describing is a bug, not an intentional regression.

Based on feedback on gopls@v0.15+ I don't think this issue is affecting a large number of users. However, we are investigating similar reports in golang/go#66145. I have not yet been able to reproduce with various types of multi-root workspaces.

Can you please share the content of your settings.json?
Also, can you try opening just the multi-module workspace folder. Do you still get errors?

[findleyr]

@xrstf some other questions:

1. Are you working in a GOPATH directory? I.e. are you working in GOPATH/src?
2. How many modules do you have in your multi-module repo? Do you use a go.work file?
3. Do language server features like hover or jump to definition work on imported symbols, even if there's a diagnostic on the import? (that would indicate that there are multiple builds involved)

Thanks.

[GrauBlitz]

I am new to Go and therefore not sure if this is really multi-module related in my case, but running go env -w CGO_ENABLED=1 solved the issue for me with the BrokenImport error on import statements. I wanted to import gtk4 (github.com/diamondburned/gotk4/pkg/gtk/v4) and with CGO_ENABLED it is now working, every other tips I found about the VSCode Go BrokenImport issue did not help me.