x/tools/gopls: add configuration to ignore certain workspace folders
stamblerre opened this issue · 16 comments
The workspace load looks at all files in a directory, but it seems it's not correctly excluding ignored files. VS Code also allows the user to ignore files with the "files.exclude" setting, which the language client should probably handle in some way? But that needs to be confirmed.
See microsoft/vscode-go#3036 for more context.
Would it make sense to ignore files and folders starting with '.' e.g. .git, .vscode, .history
Another possibility would be to respect .gitignore
This is a problem for more than just gopls. x/mod has a hardcoded module size limit, and there is no way to ignore files or directories at the same level as the go.mod file. Either .gitignore should be respected or go.mod needs an exclusion section.
I know that #37724 is tracking discussion of how files should be ignored by the go command, but we will definitely need a temporary work-around for gopls, since it will be a while before anything lands in the go command.
@heschik: Do you think that we can ignore files starting with . for type-checking/diagnostics as a work-around like @apmckinlay suggested?
What about generated files? I am ignoring .gql.go files in .gitignore (not VS Code) as that's the suffix I am using for files generated by gqlgen that I do not want to check in.
@AndreasBackx I don't understand what that has to do with gopls. You may want to file a new issue, or at least explain exactly what you're looking for here.
@heschik my apologies, I was trying to mention that there still is a use case for excluded files that gopls will most likely need to still keep track of. When using generated files, they might be ignored/excluded, but are still essential for gopls to work as desired.
I see. Whatever is done for this will need to be in sync with the go command's behavior, so I don't think we'd be able to ignore individual files anyway. The vscode issue was for ignoring directories, which should be much more clear and not have the problems you're worried about.
I just got bit by this, one of my ignored folders have about 2 million auto generated files (not go files), but for some reason that pretty much kills gopls.
Not all workspace folders can be assumed to be valid go module roots; I don't know if this is tracked in multi-module workspace issues but I just wanted to highlight it as explicit ignore setting for workspace folders is needed.
I noted how well jest.disabledWorkspaceFolders does it.
I believe that some part of this may be handled by the multi-module workspace proposal, which will not search for modules in any folder that the go command would ignore. Also, we will allow users to specify their own workspace module through a gopls.mod file, so that might be one way of managing ignored folders.
I do like the idea of a "disableWorkspaceFolders" configuration, thanks for bringing it up @ermik. Some users may just want a simple way of ignoring a single folder.
Edit: Note that this will only work for directory that are outside of a Go module. Directories within modules could not be ignored by the go command until #37724 is resolved.
It seems to me that the original problems reported on this issue are related to hidden directories, and I believe that was fixed as of https://golang.org/cl/239288. I'm going to close this issue. If you still have a problem, please open a new issue as usual and we'll take a look.
gopls is offering "import" autocomplete options for a bazel directory within my workspace (and go.mod directory) that's in my "files.exclude" list.
I'm experiencing microsoft/vscode-go#3179 and guessing inclusion of bazel directories is causing gopls to slow down, but I haven't really diagnosed yet.
In any case, I can open a new bug for this as suggested above. The issue is identical, though, so please confirm a new issue is in order.
In general, gopls doesn't really support Bazel well (https://github.com/golang/tools/blob/master/gopls/README.md#supported-go-versions-and-build-systems), so it's expected that you'd have see some odd behaviors. Folks are working on bazelbuild/rules_go#512, which will enable us to improve support for Bazel in gopls.
Whatever is done for this will need to be in sync with the go command's behavior
The go command ignores symlinks (for a particularly pertinent example, bazel-out), but gopls does not.
I can still see references to files under hidden dirs in the server log, eg
[Info - 6:05:34 PM] 2021/09/26 18:05:34 reloadOrphanedFiles reloading
Lists all files from .history.
It seems the proposal to add an ignore section to go.mod was rejected (chttps://github.com//issues/37724), so perhaps a different mechanism is needed for go tools to ignore directories that exist during development but not release.
I'll file a bug for my specific issue.