Vscode: Richer `files.exclude` config options like 'hide' or 'grayOut'

[borekb]

Currently, files.exclude items can be set to true, false or an object like { "when": "$(basename).ts" }. When an item matches a pattern, it is hidden from the explorer.

I'd appreciate more control over how these things are displayed in the explorer. For example, this would be my files.exclude section:

"files.exclude": {
    // not interested in this at all
    "**/.git": "hide",
    "**/.DS_Store": "hide",

    // compiled JS files, I'd like to be able to browse them
    "dist": "grayOut",

    // new 'mode' field for the nested object
    "**/*.js": { "when": "$(basename).ts", "mode": "hide" }
}

For backwards compatibility, true would mean 'hide'.

Note that it would _not_ change how items are e.g. excluded from search. It's purely about their appearance in the explorer.

[borekb]

Possibly related: https://github.com/Microsoft/vscode/issues/3208

[mousetraps]

Interesting idea! From your example, it sounds like what you're looking for is a more focused workflow, so you want to have the ability to customize the appearance of folders according to the specific meaning they might have for your project. Is that right?

You gave the example of introducing "greyOut" - a mode in between "hide" and "visible". Are there any other modes that come to mind as being particularly useful?

And have you tried custom file icons? E.g. some themes will mark a "test" folder or "node_modules" folder differently.

cc @bpasero

[borekb]

Yes, sorry, I was not specific enough. The modes I would be personally interested in are:

• default, visible mode: source code items etc. Things like search, Go to File etc. only work for these by default.
• hidden: same as today's true, I'd use it for items I'm not interested at all like .git, .DS_Store etc.
• grayed out: I'd use it for node_modules, Composer's vendor, our custom dist folder etc. Those are generally not my source files but useful to explore sometimes.
• nested: similar to grayed out but visually nested under its parent item. Main use case is generated items, for example, I'd nest *.js and *.js.map under their parent TypeScript file, similar for CSS and LESS, etc.
  
  
  
  • There's actually a full issue for file nesting: https://github.com/Microsoft/vscode/issues/6328. Not sure how much of it would really be needed for this and what's the overlap.
  
  

[bpasero]

We cannot overload files.exclude with this because this setting is used in many different places (e.g. also to ignore files from search results, file watching etc.). I think it would have to be a separate setting under the explorer node.

[borekb]

@bpasero What I'm proposing would not affect this, truthy values would still behave the same as today. A separate explorer node would probably lead to some duplication if I understand correctly. Is this an example of what you mean?

{
    "files.exclude": {
        "**/.git": true,
        "**/.DS_Store": true,
        "dist": true,
        "node_modules": true,
        "**/*.js": {
            "when": "$(basename).ts"
        }
    },
    "explorer.displayModes": {
        "**/.git": "hide",
        "**/.DS_Store": "hide",
        "dist": "grayOut",
        "node_modules": "grayOut",
        "**/*.js": {
            "when": "$(basename).ts",
            displayMode: "nest"
        }
    }
}

[bpasero]

Yeah the duplication is odd. I agree that maybe it would be better to keep it all in one place.

[borekb]

I understand though that the details might be tricky. Broadly speaking, I'm interested mostly in concrete scenarios as @mousetraps correctly said. For example, for node_modules, I'd like VSCode to behave like this:

• Gray them out in the explorer.
• Exclude them from search (which it currently does by default using the search.exclude setting).
• Make them secondary (very low priority) but still visible in "Go to File".

So the main question probably is where to best encode this information. I think that files.exclude is quite a good location but I don't have a deep understanding of what all this influences and how. For example, it's not very clear to me what's the relation between files.exclude and files.watcherExclude and how it would all fit together.

To sum up, I as a developer usually have three types of files in my project:

1. Source files like TS, READMEs etc.
2. Files I never want to see like .git, .DS_Store etc.
3. "Gray zone" of files like dependencies, generated files etc. They are much less important than source files but I still need to inspect them sometimes.

[jens1o]

Any news on this? I would definitely like that feature.

[borekb]

I've encountered another situation related to this: we generally gitignore generated .js files in our TypeScript project and have this .vscode config:

"files.exclude": {
    "**/*.js": { "when": "$(basename).ts" }
}

However, in rare cases, we need to commit the resulting .js files to the repo. It then looks like this on the disk:

but VSCode shows only this:

That is confusing. Maybe another visibility flag like "gitignored" could be introduced, to be able to update the when rule to something like

"files.exclude": {
    "**/*.js": { "when": "$(basename).ts || gitignored" }
}

But it's just brainstorming, I'm not sure. Maybe it's also related to various .gitignore feature suggestions like https://github.com/Microsoft/vscode/issues/178 (_Git status in File Explorer_).

[jeffreysbrother]

Sounds like a great feature @borekb. It's quite helpful, visually, having node_modules and miscellaneous dot files grayed out.

[erikdonohoo]

This is a feature in atom that is enabled by default. They don't exclude any files, but anything excluded from version control is slightly greyed out. Its a great feature.

[vscode-triage-bot]

We closed this issue because we don't plan to address it in the foreseeable future. You can find more detailed information about our decision-making process here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

[isidorn]

Closing as out of scope. Extensions can also contribute decorations to the exploerr. So I believe that is a path to potetnialy tackle this.