Better support for editing multiple go modules with the LSP

[benweissmann]

There's been discussion on the Go issue tracker about how gopls should handle editing multiple go modules at the same time -- for example, if I have a repository that contains multiple go module, and i'd like to open the repository root and then work on all the modules at once.

Right now, the only way to make this work with gopls is to add each individual module as a workspace root. This is doable, but it's frustrating when you have more than a couple modules, and also likely surprising to new users (it certainly was surprising to me!).

From the go issue tracker (golang/go#30841), it looks like gopls doesn't want to handle this within the language server itself, because there's some tricky edge cases with nested modules that probably need user interaction to handle correctly.

Does it make sense to try to tackle this in vscode-go, where we could provide some configuration options?

I'm imagining a new configuration option in the spirit of inferGopath -- something like lsp.automaticModuleRoots or something. When this configuration option is enabled, we'd add a workspace folders middleware to our registered middleware that would intercept workspaceFolders and instead of returning the actual workspace folder, it would search for all go.mod files and return those folders. Ideally, we'd also watch for added/removed go.mod files in the workspace and send the LSP DidChangeWorkspaceFolders notification. If users hit any of the edge case discussed in the gopls issue, they could turn off this setting and manage their workspace folders manually.

Does that seems like a reasonable addition / within the scope of this plugin?

[brad-jones]

Just went to the trouble of creating a test case of the issues I was having: https://github.com/brad-jones/gopls-monorepo-test-case

Was about to submit a new issue then came across this.

@benweissmann on the surface your solution sounds fine to me but I am not a vscode dev. Something needs to be done for sure.

[Owen-igaw]

@benweissmann cool, I got troubles with this issue.
My project structure is like below.

• ~/
  • ~/backend
  • ~/frontend
  • ~/logs
  • ~/public
    etc.

(The backend directory is my go module directory. It contains go.mod file)

I think many fullstack developers use such structure, and they would not wanna move their go.mod file to the root of workspace. ( In my case, there are some files like package.json, .gitignore, .gitattributes, etc. for wrapping whole repo with yarn, in root. )

Of course, @brad-jones 's solution is also cool, but his solution might makes "go.languageServerExperimentalFeatures" options are not applied. The vscode shows me that it is applied just when open directly.
Also it duplicately opens the workspaces in root.code-workspace file.

So I agree with the benweissmann's opinions, and want that the vscode-go supports automaticModuleRoots with each go.mod files!

Thanks and sorry for my bad english.. : )

[zevdg]

I just wasted way too much time trying to figure out why gopls wasn't working for me in my 3 module workspace before I stumbled onto this issue. I don't even have a multi-module repo. My modules are each in their own separate git repositories in folders next to each other on disk. I just like to hack on them together, so I open the parent folder that contains all of them. It seems like you don't even need multiple go modules to trigger this bug, Just nesting a single go module in a subdirectory and then opening the parent folder in vscode is enough to trigger this issue.

Maybe as a quick interim solution we could just detect this case and print a helpful error message like

Go modules have been detected in subdirectories of this workspace, but the Go Language Server only supports modules at the top level of the workspace. Either disable the Language Server or add these folders to the workspace.
- foo/bar
- foo/baz

where foo/bar and foo/baz are the subdirectories containing go modules.

For the record, I'm also in favor of @benweissmann's proposal, but people who don't enable automaticModuleRoots should still get a good error message, and until that proposal is implemented, we all fall into that group.

[stamblerre]

We are tracking this here (golang/go#32394) on the Go issue tracker. It might be easier to centralize the conversation there, since this issue affects other editors too.

[vlad-pro]

@zevdg
Having the same thing here. Spent a few hours trying to get around it.

[colelawrence]

This may be related to #2692 which is the problem I'm having with my mono-repo project.

[stamblerre]

Please see golang/go#36899 for the latest details on this subject. It is accurate for gopls/v0.3.0 which will be released by the end of the week.

[jbrodriguez]

Can I remove gocode, gopkgs, go-outline, guru, gorename, etc if I'm fine with gopls ?

[stamblerre]

Yep! None of those tools will be used if you are using gopls.

[jbrodriguez]

After removing a bunch of binaries from $GOPATH/bin, vscode-go displays this message and offers to install them

Below tools are needed for the basic features of the Go extension.
gocode
gopkgs
go-outline
godef
goreturns

These are my go preferences

	"go.useLanguageServer": true,
	"[go]": {
		"editor.snippetSuggestions": "none",
		"editor.formatOnSave": true,
		"editor.codeActionsOnSave": {
			"source.organizeImports": true,
		}
	},
	"gopls": {
		"usePlaceholders": true,
		"completeUnimported": true,
		"watchFileChanges": true,
		"deepCompletion": true,
		"staticcheck": false,
	},
	"go.lintTool": "golangci-lint",

Any suggestions ?

[luxuze]

same issue, my go mod file in in repo/server/go.mod.

[hyangah]

@stamblerre can we close this bug and follow up from the upstream gopls uber issue?