Today I’ve been working on getting my latest project working properly both locally and on Heroku. And since the obstacles I’m learning to overcome with this latest challenge has to do with the asset pipeline, it makes for a great post topic.
What is the asset pipeline? Well here is what the Rails Guide says:
The importance of Rails’ asset pipeline becomes apparent with it’s first feature, concatenating assets. The documentation says that by concatenating our application’s asset files we are able to reduce the number of client side requests needed to render our web pages.
Starting in Rails 3.1 all
.js files are placed into one
.css and one
.js master file respectively. Rails also adds an encrypted fingerprint into each of these files in order for them to be cached by a client.
The second feature of the asset pipeline in Rails is that it will remove all of the comments and white space from our
.css files and provide processes for minifying
.js files, provisions for us to create our own custom processes.
Using the Asset Pipeline
The preferred location for our assets in Rails3.x is in our
app/assets folder as asset files in this directory are served by the sprockets middleware which comes included with our sprockets gem.
We can still add our assets files in any of the following three locations in a Rails3x application:
app/assets are for our custom images,
.js files that are owned by our application. The ones we create from scratch, is how I interpret this from my reading of the Rails Guides.
lib/assets are for our libraries, if we have some created. They may not otherwise logically fit into our application’s assets and may be code that is reused in many of our applications. I’m really excited that building my own polymorphic library is now closer than ever!
vendor/assets are for third party assets such as a CSS framework, or if you purchased a template for your application as I have.
How does it all work?
Here is a quick illustration of both a
.css and a
.js manifest file in Rails:
This is a visual of the
.css manifest file which is named
application.css in our Rails application. The path to this file would be
And this is an illustration of the
.js manifest file. Which is named
application.js. The path to this file is
The Guide gives a good explanation on how to reference our assets into these manifest files:
Notice how we don’t need to include anything but the file name in our
require directives, even if our files are located in
vendor, pretty sweet.
If we decided that it was necessary to organize our assets inside of subdirectories, Rails makes provision for this also:
The Rails Guide points out that if we encounter a situation where we want to reference assets outside of our manifest files, we need to add them to the
config.assets.precompile in order for them to work properly in production. Here is an illustration of what that line looks like by default, the path to find the following example is at
So this is my understanding of how the asset pipeline works in action. First Sprockets will use our manifest files to figure out which asset files to include and serve. These files contain directives, which are instructions for Sprockets to determine which files to require in order to build a single
.js file. Sprockets then loads the files per it’s instructions, processes them if necessary, concatenates them into a master
.js file and if the value
true is assigned to
Rails.application.config.assets.compress. You can find this in
In my next post I’ll be continuing our overview of the asset pipeline. We’ll cover things such as using index files to include libraries, pre-processing, and go over some differences between our application in it’s development environment versus it’s production environment.
If you see anything that I could have expressed better, feel free to drop me a line. I’ve appreciated all of your comments and critiques thus far!
Categories: Ruby on rails