By the end of this lesson, you will know/be able to:
- Explain the purpose of the asset pipeline
- Explain how Heroku works with the asset pipeline
- Run your app in a production environment locally
- Be comfortable using
figaroto set environment variables
- What are assets?
- Where do assets live? (
app/,lib/,vendor/) - Why do we have the asset pipeline?
- What is Sprockets?
Work with a neighbor to research and answer these questions.
- What does it mean to precompile files? What does this have to do with Coffeescript and Sass files? Does it only have to do with Coffeescript and Sass files?
- What does it mean to minify files? Why would we want to minify files?
- What does Sprockets do and how does it fit into the precompile / minify puzzle?
Clone down, set up and start up the server for Catch 'em All (rails s) and navigate to http://localhost:3000/assets/application.js. Then open up the code for application.js in your text editor.
- Why are these not the same?
- What is a manifest (in terms of the asset pipeline)? Where can you find two manifests in Catch 'em All?
- In regular HTML files, we import CSS files with
<link rel="stylesheet" href="application.css">. How is this done in a Rails project? Where do you see this line in Catch 'em All? - How is a digest or fingerprint used on assets for caching purposes?
Done? Take a look at RailsGuides: The Asset Pipeline.
Heroku does some extra work for you with regards to the asset pipeline. In other environments, you may need to compile your assets yourself or use other tools to automate that process.
- Why would we want to see if something will work in production mode without pushing to Heroku?
- What are the
development.rb,test.rb, andproduction.rbfiles?
Catch 'em All looks fine when running in development mode (rails s).
Our challenge now is to get it running locally using the production environment AND for our assets to look the same.
Let's start off by spinning up our server in a production environment.
rails s -e productionWhat problem do we see first? How can we see our production errors?
Our logs!
We need to set our secret key.
We're going to use the Figaro gem to set our environment variables. Add gem 'figaro' to your Gemfile.
With the figaro gem, we can run
bundle exec figaro installwhich will give us config/application.yml. This file will allow us to set variables environment-wide. This file is also .gitignored, so it's safe to keep sensitive information there, including API keys.
Enter the following into your newly created config/application.yml file.
# /config/application.yml
procution:
SECRET_KEY_BASE: long_string_from_rake_secret
Check your server, and it looks like we're in better shape, but maybe not all the way there. If we inspect the page we see that some of our assets are still not loading.
Check out config/environments/production.rb. What is:
config.public_file_server.enabled = ENV['RAILS_SERVE_STATIC_FILES'].present?Things won't work in "production" unless RAILS_SERVE_STATIC_FILES is returning true.
Let's set an environment variable for RAILS_SERVE_STATIC_FILES to true. Update your config/application.yml file to the following.
# /config/application.yml
procution:
SECRET_KEY_BASE: long_string_from_rake_secret
RAILS_SERVE_STATIC_FILES: true
We then want to manually precompile. Why do you not need to do this on Heroku?
rake assets:precompileCheck out your Rails' public folder. Anything different now?
Know that
rake assets:precompilegenerates anassetsdirectory that does not update when changes are made to your codebase. Know thatrake assets:clobberwill remove that directory of precompiled assets so that you can regenerate.
Check out the section on Coding Links to Assets here.
In your gist from earlier, research and answer why we'd want to be sure we're properly using the following tags:
<%= stylesheet_link_tag "application" %>
<%= javascript_include_tag "application" %>
<%= image_tag "rails.png" %>