Most the issues under "bower is a mess" are being discussed in the https://github.com/bower/bower.json-spec repo. I have a number of proposals to improve the "main" directive and other require paths.
There is a strong dissenting opinion in bower community that it should basically be just like "npm" and none of these structured require build tool hints should be encouraged. It'd be great if others in support of the current Sprockets bower integration or this Rails Asset tool to voice their opinion and real world use asset for improving the state of the bower.json manifest.
While we all know that ruby gems have a couple of issues I think one thing was done exactly the way it should be - somehow enforced standard structure: NAME.gemspec, bin, ext, lib, lib/NAME.rb. I don't know if this is specific to only ruby community but there is at least some level of consistency which makes everyone lifes easier.
I will have to carefully read all arguments agains enforcing such structure in bower.
Sprockets has had native Bower support for some time. In Rails 3.x, there is a version restriction that prevents upgrading to the latest version, but there is a 2.2.2.backport2 version you can use to get at all the new features: http://stackoverflow.com/questions/16266528/how-to-manage-ja...
There are various solutions to managing assets in a rails application but we didn't like any of them. The one you linked to requires having separate list of dependencies and using bower directly which means hacking standard rails deployment.
Love it. Keeping JavaScript libraries up to date in Rails can be a real pain and the sprockets solution just isn't all that great. I like how you have approached this with a dead simple approach to implementation and integrating with the existing tooling (bundler/Gemfile). Good work!
This doesn't replace Sprockets at all, but integrates with it. It replaces bower "installer" with a pure ruby dependency. Sprocket still handles the runtime operation.
joshpeek, I wasn't suggesting this replaces sprockets. I was saying that the sprockets/bower integration out of the box isn't all that great, and this seems like a useful tool to help improve the situation of a common problem.
Thanks you guys, as someone who's been using Bower with Rails for a while I can tell you this was badly needed. I played with your project about a month back and really liked where it was heading. I'm looking forward to giving it another spin today.
One question I haven't managed to answer yet: what happens when a Bower-bundled component needs to use and image (or a font)?
As far as I can tell, there's not asset-path() usage, and so the link breaks in production (where image assets have <assetname>-<md5hash>.jpg filenames, for example).
This reminds me that bundler could handle dependency resolution beyond gems. Imagine:
Run bundle and all the dependencies get mapped out and installed.