After I deployed my upgraded Rails 2.3.x -> 3.1 (rc4) app to our test environment this afternoon, all of our stylesheets and JavaScript files were returning 404 errors. We had added the rake assets:precompile task to our post-deploy script and it took a while to determine why the assets folder didn’t have the pre-compiled files we expected.
In the end, the files weren’t being compiled because apparently only application.css and application.js (+ non JS/CSS files) are processed by default.
We needed to change the following configuration value as follows:
config.assets.precompile += %w( *.js *.css )
Question: why isn’t this the default?
I would have expected that anything that wasn’t necessary to process as a manifest file would just get copied into public/assets. Much of what I’ve read on the asset pipeline is essentially “stick your assets in app/assets, configure the manifest files, and it should just work”. Since the assets:precompile task didn’t spit out any information about what it was doing, it took a while to determine that it just wasn’t looking at the files we thought it would.
Is there any reason why this would not be a good value for the precompile configuration?
Thanks!
The idea is to have all your JavaScript and CSS always loaded in one shot, rather than loading bits and pieces as you move along. That way you always have the ‘world’ loaded and ready to work with, rather than having to include a whole bunch of individual files here and there.
It’s a bit of a larger ‘up front’ load, but then the browser should keep loading all the javascript from cache. So the perceived speed of the site should speed up due to having everything cached and ready to go after the first request.
This was a controversial decision to include for Rails, but so is including CoffeeScript by default. Rails has always been an opinionated framework that way.