Automatic asset paths prevent logical asset organization

I understand what you mean. For my gem oojspec and oojs I use the
manifest approach you have described:

You'll notice I have submodule to third-party libraries (Buster.js):

Then I symlink the ones I'm interested in here (yes, I know this

won’t work on Windows, but I don’t think I would get any
contributions from Windows users anyway):

The same happens with oojs. Submodules:

Linked assets:

Then the custom assets go into the lib directory instead of the

vendor one:

But I do share your feeling that it should be easier to use

third-library JavaScripts in Rails.

Maybe we could support something like AssetsDependencies similar to

a Gemfile where you would specify the url to the assets or their
repositories and what files should be required and in which order
(or specify their dependencies) so that we could run some rake task
to download them and write the manifest files. In that case we could
add those files to the VCS or just do that dynamically before
deploying like it happens with “rake assets:precompile”.

I'd love to see something like that for Rails. Currently whenever I

want to use some library with Rails I have to write my own gem when
I don’t find one, as it happened with this one:

What do you think about the idea of Rails providing something like

the AssetsDependencies DSL and a rake task as mentioned above?



Rodrigo, your symlink strategy is yet another interesting idea…

But I don’t think reinventing Bundler for javascripts is really a solution to the problem. You can still wrap it in a gem and use Bundler for that.

This isn't about reinventing Bundler as they would have quite different goals and strategy.

I already currently wrap my JS libraries/frameworks in gems when they don't already exist but replicating every JS library as a gem containing just the assets just doesn't feel right to me.

Also, while I spend about 10 minutes to vendor jQuery-layout as a gem, I think it could take a single minute to do the same through a DSL like I've described. Upgrading the library version would be even faster with the DSL approach, specially if you're the gem's author.

Think about this. Suppose there are a thousand interesting JS libraries/frameworks out there that it would worth to package as a gem.

Then suppose there are 5 Ruby web frameworks willing to extend their frameworks with plugins packaged as a gem and all of them decide to package the assets as a gem. Then you could possibly have 5,000 gems in the Ruby world that actually contain no Ruby code at all, except for the plugin glue code that could be different for each web framework.

All of that just to make it easier for users to use a JS library/framework.

+1, I see this as a mild abuse of rubygems. There are already naming conflicts.