Should we keep the aliases attribute in the devicon.json?

[Thomas-Boi]

Hello all,

As you guys might know, each object in the devicon.json has an attribute for aliases (see CONTRIBUTING.md. I understand the reason why konpa wanted aliases for "plain" and "original" version but I don't think it is applicable anymore. I think that the majority of people will use the website to find which class name they should use. There is also the devicon.json which lists all the font versions in its versions attribute.

Besides usage, I think it is a bit hard for contributors to understand and add it to the devicon.json. If it's worthwhile, we can keep this feature. However, if not many people use it, I don't see why we should keep it.

What do you guys think?

[EnisMulic]

If it's not applicable I'm for removing it as it is kind of confusing because all of the font icons look "plain" anyway.

[amacado]

I think the idea behind the aliases was to have all icons named -plain so it would be easier to use them (because you don't have to look up if a icon is -plain or -original when all font icons are named in the same manner). And when you don't want to have multiple icons looking the same (when plain and original are equal) it's a good idea to have an alias.

Since this rule was never enforced there is a mix in the font names and alias are doing things even worse (at least for contributors). When we are thinking of removing the alias we should make sure we are not breaking anything. If we are keeping the names (including aliases) for existing icons I'm fine with removing it.

[Thomas-Boi]

If we are to change the way aliases work, that will create a new major release since the new css files will be different. The build script currently generate aliases based on the devicon.json. If we are to change it, the new css files will not have the old aliases. A way to circumvent this is to do things the old way: have a devicon-alias.css in the repo that we can merge into the final css file.

Another way is to keep the attribute aliases for old icons but not for new ones. Thus, the new icons won't have any aliases while we still retain backward compatibility. I can then add a check in the build script to skip the alias generation if there are none, which is a few lines of code with barely any performance reduction.

As for introducing a new alias attribute that allows different names, I think that can work too. However, I do worry that people might get confused by the similar terms. Maybe we can use aka, also_known_as, or other_names?

[Snailedlt]

If aliases are always meant to add the icons as a plain icon as well, can't we just hardcode it?

Seems to me like it would be the same logic for all icons. If I understand correctly the usage is that if a plain icon doesn't exist, then it duplicates the original icon and uses that ss plain icon. In case original doesn't exist either, it will use any other version and duplicate that instead.

If this is the case, it can definitely be scripted with some very simple logic.
Here's some psuedocode for easier visualization.

Extremely simple logic:

If(!icon.plain) {
  icon.plain = icon.original
}

A bit more robust logic

icon.plain = icon.plain || icon.original || icon.line || icon.plain_wordmark || icon.original_wordmark || icon.line_wordmark

[Panquesito7]

This would be awesome; thank you! We could try experimenting by ourselves and see if it works properly, and if it does, then make a PR and modify the necessary components. Thomas Bui isn't working on Devicon for now, so it'll be harder to get familiarized. Clemens can help, though.

If you wanna work on this, feel free to DM me on my Discord: Panquesito7#3723

[Snailedlt]

I can take a look after my holiday (so in a few weeks), hopefully shouldn't be too hard

[Panquesito7]

Any updates on this? We could work on it and potentially have it for the next release as well. 🙂

[Snailedlt]

No updates, sorry :/
Maaaaybe I can work on it soon, but I kinda wanna get the release done ASAP though, so probably won't work on it before the release