[Feature Request] Optionally sandbox icon detection to certain folders

[zackschuster]

[EDIT] Shortly after posting this I realized the vscode icon api wouldn't allow configuration like this. I'll leave it up in case the ideas are useful for the future.

The end goal of this suggestion is to allow users to have a zero-configuration appearance as follows:

This feature could have farther reaching implications (allowing a user to define folder-specific icon associations, for instance), but as far as the "why" of this request, it's really just to make the .vscode folder look a bit cleaner.

---

Currently, icons are applied regardless of position in the file tree. This allows for very easy configuration (seriously, that config is a work of art to my eyes), but doesn't support things like limiting icon detection to certain folders. For vscode-specific icons in particular this can be tricky because names like launch.json and tasks.json can be safely assumed to be used only for vscode configuration, whereas names like extensions.json and (definitely) settings.json cannot.

A naive approach for implementing this feature would be to extend IFileExtension to include an optional folder configuration:

export interface IFileExtension extends IExtension {
  filename?: boolean; // set to true if the extension represents the whole file name.
  folders?: string[] // a whitelist of folder names to apply the extension in
  languages?: ILanguage[]; // collection of languages associated to the icon.
}

Note: all names and proposed interface changes are for demonstration purposes here, as more relevant implementations wouldn't be apparent to me

During file schema generation we can apply these folders to the defs field, skipping over matched files during application if their path doesn't match. As this is opt-in functionality, definitions without a folders property would continue to function as before.

Unfortunately, here we run into a snag: As the comment suggests, setting the folders property would immediately prevent icon application for all folders but those listed. For the vscode use case this is problematic, as files like .vscodeignore are expected to be in the root & adding the root to the proposed folders property would defeat the purpose of the sandbox. Expanding the type definition of folders would get messy fast, as we'd have more corners to check before we continue. Instead, we can add one more property to IFileExtension (also added in the defs object and consumed downstream):

export interface IFileExtension extends IExtension {
  filename?: boolean; // set to true if the extension represents the whole file name.
  folders?: string[] // a whitelist of folder names to apply the extension in
  allowInRoot?: string[] // a list of files to allow icon associations in the root directory, regardless of whitelists
  languages?: ILanguage[]; // collection of languages associated to the icon.
}

As the comment says, allowInRoot overrides folders, allowing us to move forward with the whitelist without worrying about files like .vscodeignore. Here is what our hypothetical new configuration for vscode would become:

{
  icon: 'vscode',
  extensions: [
    'launch.json',
    'tasks.json',
    'extensions.json',
    'settings.json',
  ],
  folders: [
    '.vscode',
  ],
  allowInRoot: [
    'vscodeignore.json',
    '.vscodeignore',
  ],
  filename: true,
  format: FileFormat.svg,
},

In the future, this can possibly be expanded to e.g. automatically apply uniform icons to all files within the whitelisted folders (or the aforementioned expansion of a user's ability to customize icons). However, due to the simplicity of the initial motivation & the possibility for scope creep during implementation, providing explicit support for these and other potential "side-effect" features is not included under this proposal.

Thanks for your time in reading my proposal! If a PR is welcome for this I can prepare a proof-of-concept. Have a nice day! :)

Checklist:

• I'm sure this issue is not a duplicate

[JimiC]

@zackschuster Impressive study. Thanks for your time and input. If and when the vscode API gives such an ability, it's in our highest priority implementing it.

[ciel]

What about setting the icons based on parent icon, instead of the parent folder? Does the vscode API allow that? Like this ... (I'm duplicating the src icon for example.)

{
   "icon": "src",
   "extensions": [ "custom_src" ],
   "format" : "svg",
   "extends": "src"
},
{ 
   "icon": "angular",
   "extensions": [ "environments" ],
   "children": true,
   "format" : "svg",
   "parent": "src"
}

So, it would style /custom_src/environments with the angular icon, because the icon of its parent was src

[JimiC]

@ciel It's not supported by vscode so we can't do anything without injecting code directly into the app, something we want to avoid at all costs.