ember-fontawesome
ember-fontawesome copied to clipboard
FortAwesome
FontAwesome 6 Support
Is your feature request related to a problem? Please describe. We are looking to upgrade our app to FA 6 - is the Ember library still going to be the recommended way of integrating FA6 with an Ember app?
Describe the solution you'd like I would like to continue using the ember library but with FA6 icons
Describe alternatives you've considered Are there other ways to manually integrated FA6 into an Ember application without too much rework?
I @jgadbois this is a late reply, sorry about that.
FA 6 is fully backward-compatible with version 5. This component ember-fontawesome is still the recommended way to use Font Awesome with Ember.
Thanks! Do you have npm packages for version 6 yet, or do I need to manually include the libraries?
I was able to manually include the js file and use that, however not all icons work. I believe this is because aliased icons don't work using the ember library for some reason.
I have the same request. Looks like this hasnt been resolved yet.
Yeah, I think @jgadbois is correct. We need to add support for aliased icons. Let me look into this with @jrjohnson 's help and we'll see what we can do.
Some points of interest here.
This function is responsible for normalizing the icon argument into the format that icon() expects from the @fortawesome/fontawesome-svg-core package.
https://github.com/FortAwesome/ember-fontawesome/blob/0bd1329d6be51181a52d33b1ea6c7d773b7d884f/addon/components/fa-icon.js#L13-L31
In the Vue component we updated this to use the new parse.icon() function which will resolve aliases.
So this probably needs to be ported to ember-fontawesome. Are there any other spots (the build time component?) that this might be needed?
We've been using this addon with v6 in production since the release. Not sure what is needed to make it official, but I think it's probably administrative and not code.
The issue has to do with the new version not honoring aliases. If you are not using any aliases, then yes you are probably fine. I am trying to avoid going through all my code looking for aliases and changing them to the proper name.
Alias issues should be fixed in #206 I believe. Not quite the same as the Vue component since we support a default prefix, but it appears to work. @cah-briangantzler do you have an environment where you could test this?
I have tests that check for the existence of the icons on the screen. When upgrading to
"@fortawesome/free-regular-svg-icons": "^6.1.1",
"@fortawesome/free-solid-svg-icons": "^6.1.1",
Many test fail attempting to find the icon
Adding the following does not make the test pass
"@fortawesome/ember-fontawesome": "jrjohnson/ember-fontawesome#420e236",
Does not appear to make my tests pass.
Are your tests looking for the name of the icon @cah-briangantzler? The way the aliasing parsing works is that you get the alias target. So trash-alt returns trash-can. We're probably going to have to push this as a breaking change because of that.
They are suppose to be using data-test-* for just this reason. It does look like there are a few less but yes, they are using this svg.fa-pencil-alt as the selector in many places
Yes going to have to be a breaking change. Its possible they were also using the class so more than just tests could fail, css could be applied incorrectly.
If I end up having to change a lot of these, I will prob just change to the proper name, almost the same effort
Should I go ahead and merge that PR @cah-briangantzler and get a release going? Not sure if there is anything to be done about this, but wanted to give you some more time to test.
Yea you can merge it as a breaking change. I would make sure you document the fact that the alias is NO longer the css class as it was before.
In order for me to upgrade I will have to go through my code and change the css/tests to use the real name. Which means I will go through and also no longer use the alias just be complete
Is there anything that can be done to move this PR along? I'd be happy to test.
