This will allow to support a very common scenario which is a filename with small variations depending on environments:
@robertohuertasm works for me:
"files.associations": {
"*{.prod.,.dev.,.}config": "xml"
}
@bpasero I think I didn't explain myself clearly so I've slightly changed the issue's title. I wasn't referring to that kind of file association but the one we discussed in vscode-icons #328.
@robertohuertasm got it, reopening.
+1
+1
+1
+1
+1
+1
+1
Just to add a further scenario.. Unity supports only a limited number of assets; text files must be *.txt for example. So, again, if you have let's say Lua scripts inside, the easiest option to have Unity embedding them is to rename them *.lua.txt - it would be great if icons were aligned to them being lua scripts in disguise and not text files.
+1
+1
The latest fashion is to have tests co-located with the src, using a convention such as .test.js.
Would be super helpful to be able to distinguish between regular application files and test files using custom icons!!
+1
For '.test.js': That already should work, just add that to the extensions table. You can have both js, and test.js in there and we will take the icon of whatever extension whatever matches most.
For the lua example, why not associate extension lua.txt with lua?
But the whole point is to have a specific test icon, to make it clear it is not a regular .js file.
It is a special variant of js, but could be configured to be special variant for any language with test files...
I have tests and regular app files together, but want to be able to visually distinguish the files beyond having to mentally parse the file extension in the tree view. This is a common pattern now, since our tests tool can pick up test files in the src, so we don't need to have a separate /test or /spec folder with long require chains into the root /src folder which becomes a nightmare to maintain as you scale :o
My current vsicons config:
{ icon: 'spec', extensions: ['spec.js'], special: 'js' },
{ icon: 'test', extensions: ['test.js'], special: 'js' },
I added a PR, but just discovered new icons are not in zip.
+1
@amit-srivastava-007 You are welcome to help out with my PR. I'm not a graphic designer and I don't know how to position the icons correctly (ie. centered, then lowered by one pixel).
+1
+1
+1
+1
+1
I would also like to associate ".html.tpl" to ".html"!
+1
+1
+1
+1
+1
+1
Some reaction from VS Code team?
+1
+1
+1
+1
+1
I can't figure out how to change anything... All I would聽LOVE would being able to change the colors of folders to the bright blue :)
Thanks for the聽work!
@DanJ210 are you referring to vscode-icons #596? Please, refer to our repo for further instructions on how to customize your own icons.
+1
@aeschli looking forward to this - it will have big impact in VSC usability. I mean: "+1"
+1
Hey guys any progress?
@deadcoder0904 No, there isn't any.
+1
+1
+1
Please stop commenting with '+1', GitHub has had support for reactions since March 10th 2016 (https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/)
Commenting without any substance doesn't add anything to the discussion.
@deiga Then why not close this issue?
@kristianmandrup Because the issue is not resolved?
Why would closing the issue be the solution instead of asking people to use GitHub Reactions?
@bpasero @robertohuertasm Do you know how this could be accomplished or do you know who would?
I'd love to get this working, as it's tedious to everyday tell VSCode that my docker-compose.foo.yml is a docker-compose file and my Dockerfile.bar is a Dockerfile.
And I'd love to help, but have no clue as to where to start.
Do you know how this could be accomplished or do you know who would?
No, we don't. Currently, we need to write up every possible solution and then we concatenat them while building.
I would assume it would just require using a different matcher for when the file extension expression is a regexp?
Looking into it now (for about ~5 mins).
From what I can gather, the changes need to be done in vscode-icons
defs[iconFolderDefinition] = {
iconPath: `${folderPath}${sts.iconSuffix}${iconFileExtension}`,
};
The iconFileExtension should not be taken directly from the icon JSON config loaded but be calculated on match from expression (if detected to be an expression and not a simple file extension!)
L37:
const iconFileExtension = utils.fileFormatToString(current.format);
Should instead be sth like
const iconFileExtension = utils.firstExtensionMatch(current.format, iconExprMatches);
Should somehow use data gathered from the extensions list (which should be able to take reg expressions or perhaps mappings of the form {"svg": "*.svg$")
current.extensions.forEach(extension => {
const key = extension;
names.folderNames[key] = iconFolderDefinition;
names.folderNamesExpanded[key] = iconOpenFolderDefinition;
light.folderNames[key] = hasLightVersion
? iconFolderLightDefinition
: iconFolderDefinition;
light.folderNamesExpanded[key] = hasLightVersion
? iconOpenFolderLightDefinition
: iconOpenFolderDefinition;
});
Instead should be sth like:
current.extensions.forEach(handleExtensionConfig)
function isSimpleExtension(extension) {
return typeof extension === 'string'
}
function isRegExprMappingExtension(extension) {
return typeof extension === 'object'
}
function handleExtensionConfig(extension) {
extension => {
if (isSimpleExtension(extension)) {
// old simple extension handler code
return
}
if (isRegExprMappingExtension(extension) {
// use regexp mapping to define more complex key entry to match on
return
}
console.error('BAD icon extension definition', extension)
// ignore bad entry?
}
The iconGenerator tests then also need to be extended with such functionality, similar to:
it('new file extensions are included into the manifest', function() {
const custom = emptyFileCollection;
custom.supported.push({
icon: 'actionscript',
extensions: ['as'],
format: 'svg',
});
const json = iconGenerator.generateJson(custom, emptyFolderCollection);
const def = `${settings.manifestFilePrefix}actionscript`;
const ext = json.iconDefinitions[def];
expect(ext).to.exist;
expect(ext.iconPath).not.to.be.empty;
expect(json.fileExtensions['as']).to.be.equal(def);
});
To sth like:
custom.supported.push({
icon: 'actionscript',
extensions: [{as: ["y.as", "x.as"]}],
format: 'svg',
});
Or perhaps even taking regexp expr:
extensions: [{
as: ["*.as"]
}, "bs", {
//...
}],
What do you guys think?
@deiga Why not define in your user settings:
"files.associations": {
"docker-compose.*.yml": "dockerfile",
"Dockerfile.*": "dockerfile"
},

@aeschli Great to see you can just define file associations. Not well documented I guess ;)
Still I think vscode icons should be updated to support mappings of the sort I sketched out above.
@kristianmandrup the icons extensions must generate a final json with all mapped extensions, and that's what vscode will use in order to do the mappings. This is a well defined api and there's no support for regex at all. So trying to somehow convert a regex to all possible candidates that would match would be not feasible (imagine to have to provide matches for *.yml)
As a temporal solution you have the one that @aeschli provided (which associates some files to a file type, so it wouldn't work for not supported language ids I guess) or you can use our customization options, which would allow you to associate any kind of extension to the icon you want (but still without the power of globs because the JSON that vscode expects doesn't support it - and hence this issue still stands).
@aeschli Awesome, didn't know that was possible!
Now we need to figure out how to build a system that wouldn't require custom rules for sensible defaults :)
I tried @aeschli suggestion with binary and can't get it working. Is there a list of available files.associations?
"files.associations": {
"*.{dist,disabled}": "binary"
},
+1
Is it dead ? is there no way to do this ?
I tried @aeschli suggestion with
binaryand can't get it working. Is there a list of availablefiles.associations?"files.associations": { "*.{dist,disabled}": "binary" },
@muuvmuuv There is a list in the docs.
Most helpful comment
@robertohuertasm got it, reopening.