Topic: Sharing JS/CSS in gems

At my company we have multiple Rails applications. We have a need to share code across all the applications for reuse. In upgrading our applications to Rails 3 we are moving reusable code to be shared code across applications into gems. Some helpers that we've pushed into gems reference JS/CSS that is assumed to be provided by the app. We are sharing this JS/CSS today via an svn external pulled in on the application level. The tight coupling across the gem and svn external doesn't sit well with us. Ideally, we'd push the JS/CSS into the helper gem itself or otherwise into a new gem and make it a dependency of the helper gem.

1. What is the best way to share JS/CSS code across apps?
2. Are gems the right vehicles for sharing JS/CSS? Assuming the JS/CSS is packaged inside of gems, how does the application reference the JS/CSS files?
3. Does anybody else have cases where reusable code in gems reference JS/CSS?
4. How do others reuse/share JS/CSS across applications?

Our current thinking for this is to use symlinks under public/ to point to public directories within the gems. For example:

[Rails root]/public/my_sweet_gem/ -> [LOCAL GEM REPO]/my_sweet_gem-1.0.0/public/

A request for /my_sweet_gem/some_file.js would resolve to [LOCAL GEM REPO]/my_sweet_gem-1.0.0/public/some_file.js

Symlinks would be created (if necessary) when the application boots up in development/test and during a deployment step for production.

Anybody else do something like this?

Re: Sharing JS/CSS in gems

You might be best just using a submodule (if you're using git) for this job. You can just initialize it in public/stylesheets/shared and then call whatever you need.

Alternatively, you could just host all your shared assets centrally and just hotlink to them from your application from a shared URL.

Re: Sharing JS/CSS in gems

Thanks Adam. 

Your first suggestion is basically what we're doing now, but with svn externals instead of git submodules. With respect to hotlinking: this is something we would like to avoid as we minify and collapse our assets on a per application basis.

Both of these options share the downside that assets are packaged separately from the Ruby code that references them, creating an implicit interface between the two code bases, which necessitates another layer to ensure compatibility between the two code bases. There are various ways to ensure compatibility (versioning is the obvious choice), but we are hoping to avoid this scenario altogether.