I'm struggling with trying to get fontawesome icons to show when using the yarn or npm installs. I have tried a lot of things, but am now error free in the console. I have a pro license, am using v.6 and seem to have all of the imports/calls in the right place after npm and/or yarn /webpack installs. Any advice would be appreciated.
Here is my package.json file...
"name": "group-visits",
"private": true,
"dependencies": {
"@fortawesome/fontawesome-pro": "^6.1.1",
"@fortawesome/fontawesome-svg-core": "^6.1.1",
"@fortawesome/pro-duotone-svg-icons": "^6.1.1",
"@fortawesome/pro-light-svg-icons": "^6.1.1",
"@fortawesome/pro-regular-svg-icons": "^6.1.1",
"@fortawesome/pro-solid-svg-icons": "^6.1.1",
"@rails/actioncable": "^6.0.0",
"@rails/activestorage": "^6.0.0",
"@rails/ujs": "^6.0.0",
"@rails/webpacker": "5.4.3",
"tailwindcss": "npm:@tailwindcss/postcss7-compat",
"turbolinks": "^5.2.0",
"webpack": "^4.46.0",
"webpack-cli": "^3.3.12"
},
"version": "0.1.0",
"devDependencies": {
"autoprefixer": "9",
"postcss": "7",
"webpack-dev-server": "^3"
}
}
my application.js file, (we're using webpacker with ruby on rails)...
// present in this directory. You're encouraged to place your actual application logic in
// a relevant structure within app/javascript and only use these pack files to reference
// that code so it'll be compiled.
// import Rails from "@rails/ujs"
// import Turbolinks from "turbolinks"
import * as ActiveStorage from "@rails/activestorage"
import "channels"
import '@fortawesome/fontawesome-svg-core';
// import ('./application.css')
// import ('../stylesheets/style.css')
// Rails.start()
// Turbolinks.start()
ActiveStorage.start()
console.log("Hi from application.js from all")
and I'm calling the icons like so...
<div >
<%= link_to "Home", root_path %>
</div>
</header>
<aside>
<%= link_to 'Group Visits', group_visits_path %>
<%= link_to 'Frequent Flyers', address_books_path %>
<%= link_to 'tests', calendar_path %>
<div >
fontawesome icon check: <i ></i>
solid set: <i ></i>
</div>
</aside>
</div>```
I also have an .npmrc file with my pro token in it with the correct code since we're using environment variables with font awesome in my bash file.
@fortawesome:registry=https://npm.fontawesome.com/
//npm.fontawesome.com/:_authToken=${FONTAWESOME_NPM_AUTH_TOKEN}
We are also using Rails 6. Don't know if this is causing any problems or not.
CodePudding user response:
We were able to get Font Awesome version 6 working with the following changes using yarn and file modifications...
in our application.js, we added the line...
import '@fortawesome/fontawesome-pro/js/all';
We also had to add the function...
import { dom } from '@fortawesome/fontawesome-svg-core';
and then call
dom.watch();
to replace any existing tags with and set up a MutationObserver to continue doing this as the DOM changes. This seemed like a more lightweight implementation, and you can also scope the function to only implement certain icons to speed up your app.
These changes may be very specific to our environment, Rails 6, Ruby 3.1.1, webpack, yarn, etc. The compiling/deployment on Heroku is still very slow, but it worked for us :)!
We kept these installs in package.json ...
"@fortawesome/fontawesome-pro": "^6.1.1",
"@fortawesome/fontawesome-svg-core": "^6.1.1",
"@fortawesome/pro-duotone-svg-icons": "^6.1.1",
"@fortawesome/pro-light-svg-icons": "^6.1.1",
"@fortawesome/pro-regular-svg-icons": "^6.1.1",
"@fortawesome/pro-solid-svg-icons": "^6.1.1",
"@fortawesome/pro-thin-svg-icons": "^6.1.1",
I also uninstalled and reinstalled the svg icon sets above with yarn as I don't think simply copying and posting these into a new project automatically makes them available.
These changes along with some direction from support at Font Awesome finished up several days of what seems like a straightforward install for most??
I hope this helps some lonely front ender find some peace.
Also this very detailed email from Font Awesome can help with speeding up your Font Awesome bundles!
Hi,
We generally recommend using the svg/js approach unless you really want to use css or avoid javascript. It is pretty similar in the basic approach but if you go whole hog with the javascript api you can use the library features to only import the icons you want. https://fontawesome.com/docs/apis/javascript/icon-library
Currently the way you're doing it works fine but will import all icons so the bundle is bigger than if you go with the more surgical approach offered by the api. The @fortawesome/fontawesome-pro/ package contains all our stuff so you get everything you need right out of the box. The other files are all necessary if you're wanting to get smaller bundles by using the javascript api with the library and or tree-shaking.
For this reason if you go down the library route, you'll want to not use the import '@fortawesome/fontawesome-pro/js/all' approach because that includes extra stuff that can cause conflicts as you try to narrow down the scope of your bundle. You'll need to use all the other files and will need to set up the library and import all the icons you want to use.
To recap: What you're doing now works fine if you're ok with a larger bundle since it'll pull in more than you need. It's the easiest way to implement stuff but it won't necessarily be as performant as you may want.
If you need better performance/smaller bundle sizes you will want to go down the route of the javascript api and use features like the library/tree-shaking to only import the icons you're actually using on your site. This can give you a performance boost and smaller bundle sizes but it's more complex and you have to do some extra work whenever you want to add an icon to your site.
So the trade offs are ease of use versus performance. I usually recommend for folks to use the easier method unless they're seeing performance issues on their site especially if more than one person is working on the project. Even with the larger bundles, we've designed our stuff so it's pretty performant out of the box so most people can stick with the easy method without worry. However, every site is different so your implementation might require a more performant solution than what comes out of the box, so that's when you can leverage the api to get some improvements.