I've had this problem with the asset pipeline as well, even though I don't
use submodules. I agree with Rodrigo that a solution is needed, but I have
not yet figured out what the best solution is--that's why I haven't yet
tried to contribute a solution myself.
To recap, the problem occurs when integrating third party client-side
assets that include CSS which has relative paths to images or fonts. A
couple of real examples:
background: *url('chosen-sprite.png')* right top no-repeat;
* src: url('../font/fontawesome-webfont.eot');*
The relative paths work fine in development mode but fail in production
when the CSS asset is packaged into application.css, which is at a
different directory level than the images and fonts. The ".." case is
especially tricky to work around.
If it helps, I think this is a decent set of requirements for any solution
we come up with:
- *Vendor's JS and CSS can be packaged in the minified JS and CSS files* for
the app, as described in the Rails Guide to the Asset Pipeline, even if the
CSS has relative path references to other assets.
- *Each JS library is in a directory named after it.* Personally, this
only matters to me when a JS library has multiple files (e.g., JS, CSS, and
images). For single-file libraries I don't mind having them sit together in
a single directory.
- *Let app developers keep each JS library's original directory structure
* when copying it into an app. In other words, something like
vendor/stylesheets/chosen.css. Why? So later on, when you download a newer
version, you don't have to go finding where you moved all the files.
there is one I have low confidence that it will be kept up-to-date. The
library and the gem are often written by different people. It's darn likely
that the gem maintainer will not bother updating the gem in a timely manner
every time the JS library gets an update.
- *Don't require app developers to modify the asset references in the
E.g., I don't want to replace background-image: url(bkgnd.png) with
background-image: url(<%= asset_path(bkgnd.png) %>) throughout the CSS
files in someone else's library.
- *Keep it simple*. :-) In other words, there might be an easy solution
that does not require parsing and rewriting CSS, and would work even in