Enhance go.mod resolution to look at all parent folders between a .go file and project root.

[james-lawrence]

Is your feature request related to a problem? Please describe.
Yes. I'm always frustrated when I'm working on a .go file and because I open vscode in the directory above the directory the go.mod file exists. none of the tooling works because the plugin thinks its not in a go project.

Describe the solution you'd like
the plugin should resolve the go.mod file by checking the parent files of the file being operated on.

Describe alternatives you've considered
none really, I've solved the same issue for a tool called hover resolving the pubspec file.

[hyangah]

I thought the go language server works if there is only one single subdirectory in the workspace with go.mod. Maybe that's no longer true? (cc @findleyr )

@james-lawrence If you are using go1.18+, you may be interested in configuring go.work.
https://go.dev/blog/get-familiar-with-workspaces

I proposed #2132 to automate handling of go.work but it still needs investigation and may take a while.

[james-lawrence]

@hyangah go.work solves a different problem. this is about resolving go.mod correctly for any given go file open by the editor.

[findleyr]

@hyangah yes gopls will narrow the workspace to a single module if it exists, but if two modules exist in subdirectories then it doesn't know what to do, because it doesn't know how to construct the build list. go.work is a solution to that problem.

@james-lawrence there is a long history here, and this is not as trivial as it may seem at first.

Suppose I open moduleA/a.go and moduleB/b.go in my workspace. Now suppose both moduleA and moduleB depend on a (different!) version of moduleC. If you jump to definition from moduleA->moduleC and moduleB->moduleC, would you expect to go to the same place, or different places?

If you answer 'the same place', then gopls has (for now) a way to do what you want: "experimentalWorkspaceModule": true. This creates a fake parent module requiring both moduleA and moduleB, for the purposes of constructing the build list. However, due to not being integrated with the go command, this mode can be surprising for users, as error messages inevitably reference this fake module and users cannot replicate the precise behavior of gopls from the command line. We decided it's much better to have a unified solution, which is go.work, and are planning to start deprecating "experimentalWorkspaceModule" mode in #52897.

So the solution is to create a go.work file using the modules in your subdirectories. You can use all the modules by running go work usr -r .. If you have reasons why this won't work for you, or suggestions for improving this workflow, we'd love to hear them.

[james-lawrence]

@findleyr current open buffer is the correct solution here. vscode gives plugins enough information to find the correct go.mod file to use based on the current file. I understand it may be difficult for this project; but the underlying solution to the problem is fairly trivial.

[findleyr]

@james-lawrence agreed. We want to change this behavior.

[hyangah]

The future version of gopls will offer the zero-config gopls workspace feature.
golang/go#57979

That implements various heuristics to infer the right workspace folder. One of the scenarios it's targeting is exactly this.
Closing in favor of golang/go#57979.