-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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: add configuration to ignore certain workspace folders #37697
Comments
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 @heschik: Do you think that we can ignore files starting with |
What about generated files? I am ignoring |
@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 |
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 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 |
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, |
The |
I can still see references to files under hidden dirs in the server log, eg
Lists all files from |
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. |
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.
The text was updated successfully, but these errors were encountered: