-
Notifications
You must be signed in to change notification settings - Fork 17.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/tools/gopls: support multi-module workspaces #32394
Comments
Right now, the best way to work with |
Sure 👍, but are there any plans to implement a feature like this? I'm betting most editors have this issue, not just VSCode. |
I am having a similar issue, and am currently using Our monorepo has a similar setup as the issue reporters, where we have several services with their own
My experience has been that |
How can I explicitly specify the module root for a given project? |
This depends on your editor - if you are using VSCode, this can be done via File -> Add Folder to Workspace. |
@stamblerre thank you for quick reply. I understand and can work with the limitation of having one module per-hierarchy, but it does not appear to matter unless the root folder is the one that has {
"version": "0.2.0",
"configurations": [
{
"name": "Launch",
"type": "go",
"request": "launch",
"mode": "auto",
"program": "${workspaceFolder}/src", // <- specify where Go code is located
"args": []
}
]
} Is there a similar workaround for |
Yes, for |
If there is a code path you can point to I’d love to take a stab at restoring my normality. |
We still have to make some decisions about if this is the responsibility of |
fwiw @stamblerre the scenario I mentioned above is handled by https://github.com/saibing/bingo. I guess I did mention that in my original comment. |
@sint: The way that bingo does this is technically a "hack" (see saibing/bingo@169f54c). The module root is not necessarily the directory of the current file. A better solution would be to search for all directories containing mod files and notify |
I'm under And I can not |
Hi, I've filed a proposal (#45713) for a workspace mode and config file that could be used to support the same workspace across the go command and gopls. Feel free to provide feedback if the proposal helps (or doesn't)! |
In a previous commit, we deliberately decided for using a workspace config file, and against a local .vscode directory. Previous commit message: I could not find a way to configure multiple folders per workspace when using the .vscode directory. That makes sense: the .vscode directory defines the current directory (that it is in) as a workspace. Instead, we need to have a multi-root workspace which seemingly requires the workspace settings file. Ref: https://code.visualstudio.com/docs/editor/multi-root-workspaces microsoft/vscode-go#2935 golang/go#32394 Signed-off-by: Dr. Jan-Philip Gehrcke <jp@opstrace.com>
In a previous commit, we deliberately decided for using a workspace config file, and against a local .vscode directory. Previous commit message: I could not find a way to configure multiple folders per workspace when using the .vscode directory. That makes sense: the .vscode directory defines the current directory (that it is in) as a workspace. Instead, we need to have a multi-root workspace which seemingly requires the workspace settings file. Ref: https://code.visualstudio.com/docs/editor/multi-root-workspaces microsoft/vscode-go#2935 golang/go#32394 Signed-off-by: Dr. Jan-Philip Gehrcke <jp@opstrace.com>
I don't how you guys figured this out, but adding |
Having multiple go modules in a single Workspace doesn't produce that old error anymore, but now I'm getting another error:
And then it complains about that on any action. Auto completion, intellisense and etc doesn't work. |
@dee-kryvenko Can you please check if you have the mentioned module twice in the workspace indeed? That won't work any way. And, ideally please file a separate issue with the details with how you configured your workspace (used |
Thanks - that was indeed the case. Well, not exactly - my terraform modules has been packaged together with their Terratest (Go Modules), and after Terraform got all dependencies unpacked under |
It now works like a charm. Thanks for the great changes you've made. ❤️ |
Not sure if this is this ticket or a vs-code one needs to be opened, but this capability is doing something very weird to my
So first off, is this the standard behavior? Will gopls work if I told it to kindly stop doing this as I definitly don't want local paths in a go.mod file? |
Now I get this, similar to what I was having before #32394 (comment):
Obviously I do have much more than one |
Even with the workaround to open every module as a separate root, the extension cannot find references across modules in a monorepo. I think this is another issue? |
@StarpTech My understanding is that modules open as separate workspace roots remain separate and |
…4658) ref golang/go#32394 client: add the VS Code workspace file to handle the client module Signed-off-by: JmPotato <ghzpotato@gmail.com>
gopls@v0.8.0 supports multi-module workspaces via integration with |
Go 1.18 is out. Please try out using gopls@v0.8.1 with go.work as described at https://github.com/golang/tools/blob/master/gopls/doc/workspace.md#go-workspaces-go-118 Right now, this works best if you create the go.work file before starting gopls. We're working on improving this workflow. I'm going to close this issue in favor of other open issues to improve our go.work support. |
I'm using go version
go1.12.5 darwin/amd64
and the latest gopls release and the latest go extension in VSCode.So I'm working a a project with a rather weird project structure for a Go project. It's a mono-repo of sorts. Here is the basic structure:
I usually open up the entire workspace in VSCode when I work in this project. With that I've noticed a rather weird (or maybe not) behaviour from
gopls
.You see it's looking at code in the wrong mod versions. I've discovered that it's because it's reading a
go.mod
file that were in the root of the workspace - which has since been removed. Thatgo.mod
file contained an old version of a module. Even though I were actually working ingo_service1
it preferred that one. I realized it's most likely because VSCode is invokinggopls
from the workspace level, since it works perfectly if i open up either of the service-folders in a separate window.I didn't find any flags that I could set in
gopls
. Is it possible to configure how gopls works with modules? To properly support working in monorepo's like this?This issue were spawned from this discussion: microsoft/vscode-go#2490
The text was updated successfully, but these errors were encountered: