Project Ramon

A learning journey from a Ruby noob perspective

Rails Asset Pipeline Overview


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 asset pipeline provides a framework to concatenate and minify or compress JavaScript andCSS assets. It also adds the ability to write these assets in other languages such as CoffeeScript, Sass and ERB.

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 .css & .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:

  1. app/assets
  2. lib/assets
  3. vendor/assets

app/assets are for our custom images, .css and .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 ../assets/stylesheets/application.css


And this is an illustration of the .js manifest file. Which is named application.js. The path to this file is ../assets/javascripts/application.js

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 lib or 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 ../config/environments/production.rb:


The Wrapup

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 .css or .js file. Sprockets then loads the files per it’s instructions, processes them if necessary, concatenates them into a master .css and/or .js file and if the value true is assigned to Rails.application.config.assets.compress. You can find this in config/production.rb.

The guides include a pretty long list of configurations and their path locations here.

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!

Stay tuned…


Categories: Ruby on rails

Tags: ,

3 replies


  1. Asset Pipeline Overview (part 2) | Project Ramon
  2. – What I’ve Learned So Far | Project Ramon
  3. – What I’ve Learned pt. 2 | Project Ramon

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s