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 · 8 comments
Assignees
Labels
FeatureRequest gopls Tools
Milestone

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 Tools gopls labels May 29, 2021
@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
@adonovan
Copy link
Member

@adonovan adonovan commented Jun 22, 2022

Let's use ... (which must be a complete slash-delimited segment of the pattern) to mean "zero or more complete segments of the file name", just as we do in the go command (e.g. go build ./foo/...)

@hyangah
Copy link
Contributor

@hyangah hyangah commented Jun 23, 2022

@adonovan the main motivation of this issue is to specify rules like "exclude any directory that has name 'node_modules'" (e.g. node_modules or **/node_modules in .gitignore style, or "**/node_modules": true in vscode setting style ("search.exclude" or "files.exclude"). If we use ..., should this be .../node_modules/...? That is odd.

This is more about file paths, rather than package paths, and is more about editor settings, rather than go build setting. I wonder why we want to invent our own wheel instead of already widely used glob patterns, .gitignore style settings, editor settings?

@adonovan
Copy link
Member

@adonovan adonovan commented Jun 23, 2022

I think Dylan was concerned that ** isn't required to be a complete segment (e.g. x/**y) and I suggested ... since its existing use in the Go command does have that requirement. But if both .gitignore and vscode (and apparently the LSP protocol too) already support ** with the semantics we want, then we should definitely go with that. Sorry for confusing things.

@gopherbot
Copy link

@gopherbot gopherbot commented Jun 27, 2022

Change https://go.dev/cl/414317 mentions this issue: internal/lsp: Update FilterDisallow to support matching directories at arbitrary depth

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest gopls Tools
Projects
None yet
Development

No branches or pull requests

8 participants