Only compile non-js/css under app/assets by default

[josh]

This has been bugging me forever.

I have a few packaged asset gems that have other loose files under their load path like README.mds. Those get copied over and digested to public/assets. This happens more often with bower packages.

The other thing is that these libraries have many optional parts. You don't always want all the images and other stuff copied over unless you say so.

I'm suggesting that we only auto compile "loose" files under app/asset paths. This would include railtie gems. So if you do app/assets in your gem, those are auto included. lib/assets and vendor/assets are by hand. I think that this models Rails' default autoloading strategy of app/ is autoloaded and autorequired, while lib/ and vendor/ have to be explicit.

Depends on #7964 being merged first.

/cc @dhh

[steveklabnik]

I think that this models Rails' default autoloading strategy of app/ is autoloaded and autorequired, while lib/ and vendor/ have to be explicit.

I like the symmetry here, too. First thing I thought of.

[dhh]

This makes sense to me 👍

On Oct 16, 2012, at 3:25 PM, Joshua Peek notifications@github.com wrote:

This has been bugging me forever.

I have a few packaged asset gems that have other loose files under their load path like README.mds. Those get copied over and digested to public/assets. This happens more often with bower packages.

The other thing is that these libraries have many optional parts. You don't always want all the images and other stuff copied over unless you say so.

I'm suggesting that we only auto compile "loose" files under app/asset paths. This would include railtie gems. So if you do app/assets in your gem, those are auto included. lib/assets and vendor/assets are by hand. I think that this models Rails' default autoloading strategy of app/ is autoloaded and autorequired, while lib/ and vendor/ have to be explicit.

Depends on #7964 being merged first.

/cc @dhh

You can merge this Pull Request by running:

git pull https://github.com/josh/rails only-precompile-app-assets-by-default
Or view, comment on, or merge it at:

#7968

Commit Summary

• Only compile non-js/css under app/assets by default
File Changes

• M railties/lib/rails/application/configuration.rb (2)
Patch Links

• https://github.com/rails/rails/pull/7968.patch
• https://github.com/rails/rails/pull/7968.diff
—
Reply to this email directly or view it on GitHub.

[guilleiguaran]

/cc @rafaelfranca

[rafaelfranca]

@josh could you add the CHANGELOG entry?

[stevenharman]

So if you do app/assets in your gem, those are auto included. lib/assets and vendor/assets are by hand.

When you say, "by hand," how does that work? Are you suggesting adding the lib and/or vendor paths to the config.assets.precompile setting? (Currently broken per: rails/sprockets-rails#36) Or is there a better way to limit the scope of things added by hand.

For example, if I need to vendor a jQuery plugin which also has CSS, a font face, and an image sprite, I'd add the .js and .css to vendor/assets/javascripts and vendor/assets/stylesheets. I would also vendor the sprites and fonts in vendor/assets/images and vendor/assets/fonts, respectively. Adding the entire vendor/assets path seems overkill, but manually specifying each asset individually seems tedious (though that might be by design).

[hongliang-goudou]

This is a REALLY BAD change. Very confusing. Many css libraries have to tell their users to add a special line to their config/application.rb:

config.assets.precompile += %w(*.png *.jpg *.jpeg *.gif)

[shamabbas]

This worked for me finally after wasting so many hours researching.

config/application.rb
config.assets.precompile += %w(*.png *.jpg *.jpeg *.gif,
"fontawesome-webfont.ttf",
"fontawesome-webfont.eot",
"fontawesome-webfont.svg",
"fontawesome-webfont.woff")

# config/application.rb
config.assets.precompile << Proc.new do |path|
  if path =~ /\.(css|js)\z/
    full_path = Rails.application.assets.resolve(path).to_path
    app_assets_path = Rails.root.join('app', 'assets').to_path
    if full_path.starts_with? app_assets_path
      puts "including asset: " + full_path
      true
    else
      puts "excluding asset: " + full_path
      false
    end
  else
    false
  end
end

environment/production.rb
config.serve_static_assets = true

Then I ran bundle exec rake assets:precompile RAILS_ENV=production and pushed it.

[fny]

If we're going for true parallelism, there ought to be a manifest file of sorts for images and fonts. Something just feels awkward about listing umpteen image and font paths in the app configuration.

[jejacks0n]

They load in development, but when you precompile them they aren't generated? The disparity between the different configurations (environments) shouldn't be there IMO. I'm fine with this change, but I think it should be symmetrical and behave in an understandable and consistent way.

It's pretty clear by the issue being referenced on so many other issues that it's caused a considerable amount of confusion and issue churn. I'm happy to jump in and contribute to that if there's some consensus.

[rafaelfranca]

@jejacks0n we are already on this rails/sprockets-rails#84

[searls]

I agree with @steveklabnik's sentiment at the top that the symmetry with lib/vendor in ruby code is nice, but AFAICT in practice this is actually quite dissimilar when you consider that merely "requiring" an asset isn't actually enough to get it copied over during rake assets:precompile.

That is to say, if I have a font in vendor/assets/fonts/ and I "require it" from some css.erb file in vendor by way of the asset_path helper (e.g. url(<%= asset_path('foo.woff') %>)), then what I would expect as a user is that the font will be included during precompilation. Of course, it isn't, and instead I have to reference that particular asset from my application's configuration. As a result, the nice symmetry that seems to have been the motivation for this PR is lost.

(I decided to just give in and start putting all non-CSS, non-JS 3rd party assets into app/assets to save myself the hassle and leaking references)

[jcarlson]

This is an unfortunate opinion Rails has taken on this topic. This change has made it near impossible to use Bower to manage any front-end library that includes images or fonts (Bootstrap, jQuery-UI). The CSS and JavaScript work fine, but no matter how I configure my app, I cannot get the vendored images to end up where the CSS (relatively) expects they will be.

Part of that is my doing, because I'm inlining the Boostrap CSS (into /assets/application.css) instead of serving it from it's "vendored" path of /assets/bootstrap/dist/css/bootstrap.css, but doesn't that defeat the purpose of Sprockets if I have to make all my vendored stylesheets separately precompiled packages?

I don't know guys... this is one of the more maddening problems I've dealt with recently and I lost a lot of time on it because there is a TON of documentation about how to configure Bower to work with Rails... and those instructions just don't work or don't account for images and fonts included with Bower packages.

As of now my options are 1) use gems for assets (which are often out of date) or 2) go back to manually cultivating the vendored assets. Blegh.

[matthewd]

@jcarlson I'm not sure how closely this PR relates to the problem you're describing.

Anyway, suggestions for improvement are always welcome.

[jcarlson]

Recent versions of Sprockets seem to be aware of bower.json package descriptors. If package publishers are correctly declaring all the resources their package exposes, images and fonts included, is there any reason why Sprockets or Rails couldn't automatically copy over those binary resources, even if they are in vendor/assets or lib/assets? The bower.json file could serve as the "manifest" suggested by @fny above. As an example: https://github.com/twbs/bootstrap/blob/master/bower.json#L16-L24

[jabberfest]

With RAILS_ENV=development:

With this change I get the expected error message of Sprockets::Rails::Helper::AssetNotPrecompiled if trying to do something like

<%= javascript_include_tag 'foo' %>

in my view. This is assuming foo.js is in "vendor/assets/javascripts"

This is also assuming I did NOT set the following:

 Rails.application.config.assets.precompile += ['foo.js']

However, I can still access the foo.js resource if not using a rails view helper.

If I have something like

<script src="assets/foo.js"></script>

in my view helper.

The weird thing is foo.js never appears in the public directory since it's not precompiled, yet it is still available accessing the url without a view helper.

You would expect to not have the resource available. I only bring this up because it could give a developer a false sense of app stability. The app would fail to run in production because the foo.js resource would not be compiled.

I've seen this problem happen more when requireJS is used without a javascript_path helper. The app would work in development, then fail in production when the resource could not be loaded.

Even though this ticket is closed, hopefully I can get some feedback. I'll wait a week or so, and open a new ticket to get some thoughts.