Is it possible that we have a parameter in settings to allow user specify the sub-directory as root of Go project

[sillydong]

Is your feature request related to a problem? Please describe.

We always see such message if we open a repo and go.mod is not under the root directory of that repo. I tried the build.expandWorkspaceToModule setting, it does not recognize the sub-directory contains go.mod even it is the only sub-directory which contains go.mod file.

Describe the solution you'd like

Provide a setting to allow user specify the sub-directory as root directory and pass it to go plugins.

Describe alternatives you've considered

I tried build.expandWorkspaceToModule but not helping.

Additional context
Add any other context or screenshots about the feature request here.

[hyangah]

@sillydong Have you tried Go workspace https://go.dev/blog/get-familiar-with-workspaces ?
When you work with multiple modules at the same time or have a go module somewhere nested under the VS Code workspace, create a go.work file and tell the language server (gopls) the module location.

We hope that a future version of the language server (gopls) will handle this somewhat automatically (golang/go#57979) but until then, go.work is the best option I am aware of.

[sillydong]

It's just when I use go.work, I found it cannot recognize the vendor directory under the module. Even though all deps are vendored in the module directory, it queries and downloads packages from network and there will be error like tidy: diagnosing file://{filepath}/go.mod err: exit status 1: stderr: go: downloading {package}. When I open the module directory as root directory, it can recognize the vendor and parse it in right way.

[sillydong]

Like build.expandWorkspaceToModule's behavior, it will detect parent directory and children directories. If there is exactly one child directory containing a go.mod file, narrowing the scope to that directory if it exists. We can see from gopls' output go dir <some directory>. If the repo contains multiple go.mod files, gopls could not determine which directory to use and then errors occur in OUTPUT. The directory it detects fits the vendor well. So is it reasonable to provide a way to set that value manually?

[hyangah]

How many subdirectories contain go.mod files? Gopls should recognize a module in the subdirectory if there is only one module. (I just verified it is still working) If it fails, I am afraid that implies there are multiple modules underneath. In that case, users will encounter the same issue as soon as they open a file outside the current module boundary.

golang/go#57979 work is underway - which detects module roots automatically. Can we wait for it instead of adding one more configuration which eventually will not be needed and confuse users for longer time?

[sillydong]

Like I said in #2967 (comment), the directory contains multiple subdirectory that contains go.mod, so I'm hoping if we can allow user to manually set a value for gopls to use in go dir <some directory>

Also I have tried go.work, but it keeps querying for packages even when I have all deps in vendor directory. This cause the workspace to error everywhere.

I will wait and see if golang/go#57979 can fix the situation. Thanks for sharing this info.

[cletter7]

Hello @hyangah, could you share if there is any timeline for the golang/go#57979? I have a similar issue (described here). Just want to understand when is the feature expected. Or maybe there is some workaround?