search.exclude does not work for searching symbols across a workspace

[imdadahad]

• VSCode Version: Code Insiders Version 1.22.0-insider (1.22.0-insider)

Steps to Reproduce:

1. Open a javascript project with a node_modules folder (couple packages installed)
2. Search for a symbol across the project
3. It will show results from the node_modules directory even if you have added the following your user/workspace settings:

"**/node_modules": true,
"node_modules": true

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• VS Code freezes when removing 'node_modules' folder from external terminal, forcing to close (#20480)

[roblourens]

Is the "Use Exclude Settings and Ignore Files" button toggled on? (bottom right)

[imdadahad]

This is related to the Symbol search option (https://code.visualstudio.com/docs/editor/editingevolved#_open-symbol-by-name), not the find in all files as you've shown above.

As shown it seems to retrieve results from node_modules despite having included the following in search.exclude:

"**/node_modules": true,
"node_modules": true

[roblourens]

Those settings don't impact symbol search. Not sure whether symbol search is supposed to include node_modules stuff @mjbvz

[imdadahad]

Oh really, would've thought anything that included node_modules would raise alarm bells given that indexing that folder is super slow. It would explain why it's noticeably slower to search for a symbol compared to Sublime.

[mjbvz]

@imdadahad Do you have a jsconfig.json file? If not, try creating a simple one at the root of your project:

{
    "compilerOptions": {
        "target": "ES6"
    },
    "exclude": [
        "node_modules",
        "**/node_modules/*"
    ]
}

This should exclude node_modules files from symbol search

[imdadahad]

Yes, I have this already.

[priezz]

I have exactly the same issue. Results from 'node_modules' are shown when doing the symbol search. How to exclude specific directories?

[imdadahad]

Any update on this, curious to know whether it's an actual bug/issue with config maybe?

[dkozickis]

Any update please?
Same behavior on VSCode 1.28.2 / Windows 7

React TS project, trying to search for store symbol (part of application), I get following suggestions, with a million suggestion from node_modules, the store I'm looking for actually being on 8th place.

My settings.json

"search.exclude": {
    "**/node_modules": true,
    "**/bower_components": true
  },

[bernatfortet]

Any updates on this?
Searching workspace symbols is an amazing feature but seeing all the stuff from node_modules makes it less usable.

Thanks!

[dkozickis]

@mjbvz, @roblourens (sorry to tag you both, just hoping to get some reply and direction)

Summary is at the bottom.

So, I've code dived a bit, finding is that Workbench search (Quick Open) or whatever anyone calls it, is not using search.exclude settings to filter the results for symbol search.

getWorkspaceSymbols is what supplies symbols data to the Quick search

https://github.com/Microsoft/vscode/blob/c63c97c12848e85769e717209b73110e83c18ef6/src/vs/workbench/parts/search/common/search.ts#L57

Under the hood it calls TS Server 'navto' facilitated by TypeScriptWorkspaceSymbolProvider

https://github.com/Microsoft/vscode/blob/97c753fa1f9db7b39a91189807313a4bd344f45e/extensions/typescript-language-features/src/features/workspaceSymbols.ts#L23

Anyway, long story short, Symbol search results are pushed to results array around here (via OpenSymbolHandle)

https://github.com/Microsoft/vscode/blob/850bbb275e648c75e3804f38f179642c7fa2d007/src/vs/workbench/parts/search/browser/openAnythingHandler.ts#L111-L113

And then are returned to Quick Open controller.

Summing up:

1. Quick Open symbol search does not filter the results based on VSCode search config
2. Not a bug - a "feature"

I'd like to try my hand at adding this to VSCode, if maintainers can point me in the correct direction.
What I'm thinking is implementing filtering in openSymbolHandler

https://github.com/Microsoft/vscode/blob/29fe3f317ffa513746f456ee6026796638ada21a/src/vs/workbench/parts/search/browser/openSymbolHandler.ts#L136

Should it read from same search config or implement it's own setting? E.g. search.filterSymbols (dunno)? Also - if this was designed this way from begging - maybe there's some reasoning to it?

Appreciate comments.

[dkozickis]

@mjbvz @roblourens

A kind ping/reminder - if you could have a look and provide direction/comment?

[roblourens]

Sorry I don't know what the intent is or whether this has been considered, @mjbvz?

[dkozickis]

A kind ping @mjbvz :)

[mjbvz]

@roblourens I feel workspace search should probably respect search.exclude but I don't think TS should be the one to determine this. If we to enable this, one option is to:

• Make VS Code filter the returned results.
• And also encourage providers to consult the search.exclude so that they don't return results that will be filtered out

[roblourens]

Yeah if there is a max result count, then the provider definitely has to do the filtering. Hopefully eliminating results saves more time than it costs to do the glob matching.

[dwelle]

@bpasero

should have made clear, this requires the new quick open to be used, not the old one. The new is F1 > Quick Access > #. It will be enabled by default over coming days.

Instructions unclear. I don't have any Quick Access in latest insiders.

[bpasero]

I should have posted here, the feature was pulled out, currently search.exclude is NOT being used for workspace symbol search.

[peterldowns]

I think it makes sense for the language server plugins to be able to resolve those symbols, but also that when quick-searching for symbols, to allow users to say "i don't want to be able to quick-resolve to symbols deep in my node_modules tree". It's useful to be able to find all the symbols in use in my project when jumping through and debugging stuff, but when i'm quick-opening I ALWAYS want to find a symbol that I have defined in my own project, not some deep library code.

[samuliasmala]

Is there any workarounds to exclude node_modules from Go To Symbol in Workspace? Now the feature is not very useful when you have a large amoun to packages installed in the project.

[kbysiec]

I was suffering the same and decided to develop an extension for easy navigation among workspace files and symbols. Hope it helps somebody.

It is fully customizable so the user can easily decide which folders are included/excluded from the currently opened workspace/project.

https://marketplace.visualstudio.com/items?itemName=kbysiec.vscode-search-everywhere

Enjoy.

[adesnmi]

Does anybody know the status of this?

[ddadon10]

+1 on this, I would to be able to exclude folder from symbol search

[CarinaChenot]

+1 as well, the symbol search feature is not really usable as it is without being able to exclude node_modules from results

[ZeWaka]

bumping this, this is extremely annoying for JS projects we bootstrap in

[imdadahad]

Would've had more luck buying BTC than having this resolved 😒

P.S. Still using PyCharm...

[timlau]

Any news on this one ?
(**/build/** in seach exclude )

[nvthuong1996]

I would to be able to exclude folder from symbol search

[CasualEngineerZombie]

It appears to have occurred as a result of the installation of a strange extension. I was able to remedy the issue by disabling all of the extensions one by one.

[selrond]

I'd also love to see this implemented, as many others before me.
Although it's been 2 years since @dkozickis broke it down, it seems like a low-hanging fruit that’d bring great value.

@mjbvz could you provide some insight into this?

[selrond]

If it’s reasonable for a first-time contributor to this repo, I’d try my hand at it

[alexn-s]

are there any news on this subject?
i think its an important feature for vscode

[EcksDy]

Goto symbol is unusable when it's showing results from dist/out/nodemodules etc.
Will this setting be implemented?

[mjbvz]

I'm locking this issue since there have not been any constructive comments in quite a while

If you're interested in fixing this, please open a new issue that proposes what the fix would look like at a high level. If that looks good, then we can move on to an implementation