Skip to content
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 matching directories at arbitrary depth using the directoryFilters setting #46438

Open
cespare opened this issue May 29, 2021 · 4 comments

Comments

@cespare
Copy link
Contributor

@cespare cespare commented May 29, 2021

I have some very large node_modules trees that cause gopls to fail. The recently-added directoryFilters configuration setting is a partial workaround for this, but the paths it accepts are always interpreted relative to the workspace root.

There are multiple large node_modules directories in my workspace and the set might change in the future. I don't want to keep directoryFilters in sync with this. Instead, I want to globally ignore node_modules directories everywhere, in all workspaces, forever. But there doesn't seem to be any way to specify an unrooted path in directoryFilters.

I suggest adding a way to do this. One question is the syntax to use. If we were designing this from scratch, perhaps a rooted path (-/myproj/node_modules) could indicate workspace-relative and unrooted path (-node_modules) could indicate "match this directory at any depth". (This would be similar to how, for example, gitignore works.)

But since that option is foreclosed at this point, here are some other ideas to get us started. A leading * could be used to indicate "match at any depth": -*/node_modules. That resembles, yet is confusingly different from, shell glob syntax, so perhaps * could mean "match any single directory" and ** could mean "match any depth"; then I could use -**/node_modules.

@gopherbot gopherbot added this to the Unreleased milestone May 29, 2021
@myitcv
Copy link
Member

@myitcv myitcv commented May 29, 2021

In the somewhat related #41504 (comment) I suggested using the .gitignore approach - that would seem to work here too?

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Jun 1, 2021

/cc @heschi here for input, since he designed this feature

@stamblerre stamblerre removed this from the Unreleased milestone Jun 1, 2021
@stamblerre stamblerre added this to the gopls/unplanned milestone Jun 1, 2021
@heschi
Copy link
Contributor

@heschi heschi commented Jun 1, 2021

As you say, it's moot now, but FWIW I think using / for the project root would be very ambiguous with absolute paths, which is why I started with relative paths. I suspect it's not a problem in the context of a Git repository, but editor settings have a much weaker context.

I'm in favor of using ** to mean match any number of folders, including 0; I just didn't get around to implementing it.

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 2, 2021

Change https://golang.org/cl/347297 mentions this issue: internal/lsp: exclude node_modules in the workspace root by default

gopherbot pushed a commit to golang/tools that referenced this issue Sep 2, 2021
It is unlikely that users want gopls operating on their node_modules
directories, so we should exclude them by default. If a user wants to
include them, they can override their directory filters setting.

This doesn't exclude *any* directory named "node_modules", so we still
need to implement golang/go#46438 to exclude node_modules completely.

Change-Id: I03c42208e62390dc35e44ac5176422ddf8dc53f7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/347297
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
@stamblerre stamblerre self-assigned this Sep 10, 2021
@stamblerre stamblerre removed this from the gopls/unplanned milestone Sep 10, 2021
@stamblerre stamblerre added this to the gopls/on-deck milestone Sep 10, 2021
@stamblerre stamblerre removed their assignment Oct 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants