Permalink
Browse files

Require assets in all environments by default and provide a way to op…

…t-out from uglifier.
  • Loading branch information...
1 parent d5e8722 commit 3da3df8fcbe59d6433d1bf6632f73a0161bf48fe @josevalim josevalim committed Jul 11, 2011
@@ -70,8 +70,13 @@ def asset_environment(app)
if assets.compress
# temporarily hardcode default JS compressor to uglify. Soon, it will work
# the same as SCSS, where a default plugin sets the default.
- env.js_compressor = LazyCompressor.new { expand_js_compressor(assets.js_compressor || :uglifier) }
- env.css_compressor = LazyCompressor.new { expand_css_compressor(assets.css_compressor) }
+ unless assets.js_compressor == false
+ env.js_compressor = LazyCompressor.new { expand_js_compressor(assets.js_compressor || :uglifier) }
+ end
+
+ unless assets.css_compressor == false
+ env.css_compressor = LazyCompressor.new { expand_css_compressor(assets.css_compressor) }
+ end
end
env
@@ -15,7 +15,7 @@
# If you have a Gemfile, require the default gems, the ones in the
# current environment and also include :assets gems if in development
# or test environments.
-Bundler.require *Rails.groups(:assets => %w(development test)) if defined?(Bundler)
+Bundler.require *Rails.groups(:assets) if defined?(Bundler)
@rmm5t

rmm5t Jul 12, 2011

Contributor

@josevalim I'm glad to see this change, especially so production deployments work as expected out of the box. However, is there still a reason to keep around the Rails.groups method? It seems like left-over cruft now. I don't think it's used anywhere else, and I think this would be more straight forward:

Bundler.require :default, Rails.env, :assets if defined?(Bundler)
@josevalim

josevalim Jul 12, 2011

Contributor

We still need the Rails.group for everyone who won't be able to load assets stuff in production, for example, Heroku. Thanks for checking though!

@rmm5t

rmm5t Jul 12, 2011

Contributor

Valid point, but assuming nothing in public/assets (because of no easy assets:precompile on Heroku), Sprockets could handle the Sass and Coffeescript just fine (with help of therubyracer gem or the new Cedar stack). Sprockets might need to be modified to continue to serve static assets like images in production, but as long as everything in production is served with Cache-Control headers, Heroku's varnish layer would make everything seemless, or no? To me, this would make a Heroku deployment of a Rails 3.1 app simpler. This would also ensure that more traditional Rails 3.1 deployments work more closely to how they do in development mode, and if you want to improve asset performance, you can always still optionally run assets:precompile.

@josevalim

josevalim Jul 12, 2011

Contributor

We are working together with Heroku developers on this and they don't want exactly what you mentioned: depend on therubyracer (v8) or node.js in production runtime. They just want to depend on it in the explicit compilation step (with assets:precompile).

module <%= app_const_base %>
class Application < Rails::Application

0 comments on commit 3da3df8

Please sign in to comment.