Feature request: change fortawesome => a less confusing name + clearer version naming

[peternixey]

Describe the problem you'd like to see solved or task you'd like to see made easier

##1. Naming confusion
Getting Fontawesome to work in Angular is non-trivial with sufficient steps that it's quite easy to go wrong. Going wrong then involves going back through code with a fine tooth comb to figure out what's amiss.

Often in the stages before fontawesome works it just doesn't work and doesn't work silently. The use of "fortawesome" as a name adds confusion and means constant double-checking spellings. Using a completely different package name would make this far easier to debug. It's a clever name from a branding perspective and I love the idea but it's sadly a bit of a headache when you're actually in the code.

Sadly as I write this I realise there is basically no way you can change the name of the whole of the Github organisation - but it may at least be food for thought. When I first started using the repository I was questioning who fortawesome was, how is it related to fontawesome, is it official, what does it even mean. Now I see that someone else took your github name first but the naming initially caused a lot of questions in my head!

As I think all of this through, even just a clear explanation as to who Fortawesome is at the start of the readme file along with an assurance that the only place that the "r" will show up is in the org name would help a lot.

There are a lot of nuances in Fontawesome and "r"s and "s"s have a lot of significance throughout the repository and icon set. Removing as much confusion as possible would help focus understanding where it's really needed e.g. fas v. far.

##2. Version confusion

Fortawesome has a different version to Fontawesome which itself obviously has a different version to angular. This leads to a multiplicity of combinations which themselves are further confusing.

In the table above I immediately wonder - which version of Fontawesome is in each of those packages? Are they all Fontawesome 5?

This could be made easier if the Fortawesome version was clearly related to the angular and fontawesome versions that it maps to. This might lead to unconvertional version naming but would make installation far easier e.g.

Angular v 9, Fortawesome v0.6, Fontawesome 6: => v0.6_fa6_ng9
Angular v 10, Fortawesome v0.6, Fontawesome 6: => v0.6_fa6_ng10
Angular v 10, Fortawesome v0.7, Fontawesome 6: => v0.7_fa6_ng10

It's not quite clear to me whether Fortawesome's version relates directly to the Fontawesome version. But if it does then maybe more helpful to be explicit of that.

Is this in relation to an existing part of angular-fontawesome or something new?

Existing part - naming conventions.

What is 1 thing that we can do when building this feature that will guarantee that it is awesome?

Just make all of the naming clearer so that it's more explicitly debuggable!

Why would other angular-fontawesome users care about this?

There are a lot of moving parts to getting Fontawesome working in a project. It's not as straightforward as other projects and this would help reduce the complexity.

On a scale of 1 (sometime in the future) to 10 (absolutely right now), how soon would you recommend we make this feature?

2

Feature request checklist

• [x ] This is a single feature (i.e. not a re-write of all of Font Awesome)
• [ x] The title starts with "Feature request: " and is followed by a clear feature name (Ex: Feature request: moar cowbell)
• [x ] I have searched for existing issues and to the best of my knowledge this is not a duplicate

[devoto13]

In the table above I immediately wonder - which version of Fontawesome is in each of those packages? Are they all Fontawesome 5?

Until recent, version 5 was the only version. So it was not really a problem before. It also says at the top of the README file:

Official Angular component for Font Awesome 5

I'm opposed to having complex versions, but aligning versions with the main FontAwesome releases sounds like a good idea. Then we can have angular-fontawesome@5.x for FontAwesome 5 and angular-fontawesome@6.x for FontAwesome 6, which should be easy to understand. This implies that we no longer follow SemVer, same as the main FontAwesome project. This will disappoint some people, but all in all should be an acceptable compromise.

---

As for the naming convention, we inherit it from the main FontAwesome project, so I'll let @robmadole or @mlwilkerson to chime in. It may also be better to discuss such changes on the main repository instead: https://github.com/FortAwesome/Font-Awesome.

[robmadole]

Ok. I know the naming is confusing and I'm going to earmark this issue for further discussion as we proceed with version 6.

But here are my initial thoughts:

1. I would very much like to keep semantic versioning in the JS component libraries
2. I would very much like the version of Font Awesome (5 or 6) to not matter. That means that angular-fontawesome would support both versions (including fontawesome-svg-core@[5|6] and all SVG icon packages)

The only possible backward-compatible issue is with the TypeScript package that @devoto13 brought up. We need to think through it.

[peternixey]

Thanks for considering all this guys. I’ve been using Fontawesome ever since you first launched it and was one of your first Kickstarter backers so am super grateful for all your work. 🙏🏻

[devoto13]

Now that the suggestion has been communicated to the Font Awesome core team I think we can close this issue. While the current versioning scheme has some problems I don't believe we'll be changing it specifically for the angular-fontawesome and the change should be initiated by the core team in all packages at the same time for consistency. Consequently, I'm closing this issue as not actionable for now.