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: remove the "expandWorkspaceToModule" setting #63536
Comments
I think I have a use, but I'm not sure where to comment, so here it goes. What I'm noticing is that using neovim's lsp implementation I'm running into this issue: neovim/neovim#23291 I most recently noticed this issue after adding a
Content of
Combine this with the gopls issue with globbing seen here: #41504 We get the following behaviour:
I think this behaviour is related to this issue and the In my case I would expect Alternative behaviour could be only loading the glob for any root (sub-path) that matches a I'm all ears to hear about workarounds or solutions to my problem. |
Thanks for raising this issue, and for the detailed explanation of the performance bottleneck you're experiencing. I was unaware of that neovim issue, and will keep it in mind. I think I may not have explained clearly that the current default behavior will remain unchanged (which is I looked into your use case, and don't think that it is affected by |
I filed #63742 to follow up on the overly broad watch patterns. |
Thank you for the clarification. I think the behaviour of Since this is kind of a 2-part issue (nvim lsp watch files implementation + gopls overbroad watchfiles glob) I decided to try to change the lspconfig.gopls.setup({
on_attach = [...],
capabilities = [...],
settings = [...],
-- override root_path for issue: https://github.com/golang/go/issues/63536
root_path = function(fname)
local root_files = {
'go/go.mod', -- monorepo override so root_path is ./monorepo/go/** not ./monorepo/**
'go.work',
'go.mod',
'.git',
}
-- return first parent dir that homes a found root_file
return lspconfig.util.root_pattern(unpack(root_files))(fname) or lspconfig.util.path.dirname(fname)
end,
}) And now the number of watchfiles is back down in the ~3k instead of in the ~15k. Note: The neovim lsp watchfiles function being slow still exists, but the delay is ~20ms and not like ~20s. Alternatively users can just disable the watchfiles function entirely following steps here: neovim/neovim#23291 (comment) |
I use this setting with vscode. My work uses some fairly large mono repos with Bazel. Most of the Go parts can use the standard Go tools, but not all. I like to open just the directory I am working on (e.g. a single library, or a single main program), since then all of VSCode's search and navigation features work well, without stuff I don't care about. To be clear, the directory looks approximately like:
And I open the sub-directory within the Go module called
which as far as I understand it, should remove everything from gopls's build, but it does not seem to work. I have also tried variants that include If I set |
I have the same use case as @evanj. I use vs-code and my work uses a very large monorepo and bazel and I like to load only the service directories I care about (eg I haven't touched my config in a long time, but I distinctly remember having to add I will experiment with turning it off, since maybe the heuristics used etc have improved and report back, but I imagine it is still an issue. |
Thanks very much for the detailed feedback! I think it's probably incorrect to expand the workspace if GOPACKAGESDRIVER is set, so perhaps we can just fix the default behavior in that case. I'll investigate. |
Per the rationale provided in #57514: remove this unnecessary setting, in favor of always expanding/contracting the workspace as necessary (the current behavior with
"expandWorkspaceToModule": true
). If you need this setting, please leave a comment explaining why.The text was updated successfully, but these errors were encountered: