How to set go mod path

[jaskerv]

trafficstars

Check for existing issues

• [X] Completed

Describe the feature

My project is using a single root go mod in a sub directory folder. If I open my zed at the root of the repo, zed cannot detect my go mod folder and give me intellisense. To fix this, I can open zed in the go mod root folder but lost context for the rest of my repo.

Ideally I can configure this per workspace or let zed auto detect the go mod folder.

Is there a way to do this?

Thanks

If applicable, add mockups / screenshots to help present your vision of the feature

No response

[mrnugget]

With Preview release 0.124.2 we now pick up gopls in a project worktree, if it is findable in the PATH of a shell spawned in that directory. (See here: https://github.com/zed-industries/zed/pull/8188)

That makes me wonder: is it possible to specify via ENV war where the go mod is located?

[jaskerv]

is there a config like workspace for vscode? If I have repos where go.mod is at root or monorepos/polyrepos in a subdirectory, it would be nice to configure it per project.

[mrnugget]

Yeah, you can set config per project in .zed/settings.json, but we don't have the ability to set the rootpath per language yet. I'll look into it.

[mrnugget]

I got it working! The trick is to use Go workspaces.

If you look here https://github.com/golang/go/issues/36899 you'll see that what we're discussing here was marked as Unsupported by the gopls team:

Open a directory that contains a module in a subdirectory. gopls will not work in this case.

But turns out that was solved with the introduction of Go workspaces in 1.18. Here are the docs:

https://github.com/golang/tools/blob/master/gopls/doc/workspace.md#when-to-use-a-gowork-file-for-development

So, given the following structure of my repository:

.
├── README.md
├── go-subproj
    ├── file2.go
    ├── go.mod
    └── main.go
├── next-subproj
└── rust-subproj

gopls is started in the root of the repository, but it doesn't work in go-subproj. What does help is to use the mentioned Go workspaces:

go work init
go work use go-subproj

That creates the following go.work file in the root of the repo:

go 1.22.0

use ./go-subproj

And if I now open Zed at the root of the repo, it works!

I think that this is better for us as a solution, because if we had to spawn gopls processes in each directory with a go.mod, we'd soon run intro trouble (what if you use workspaces? etc.) So for now I think this is what we should go with (until we have proper extensions that could maybe add more detection here)

[jaskerv]

Thanks! That worked well! Now I can play around with Zed 🎉