Add support for Bowerfile

[eddietejeda]

I've used bower-rails and rails-assets and both have their advantages.

rails-assets

pros:

• Easy to setup and deploy
• Makes continuous integration simple (like with circle)
• Uses a familiar format for installing gems

cons:

• Unscalable syntax (Question: Is it possible to use unregistered bower packages, just from git endpoint? #94)
• Proxy site can be slow (But I won't dwell on that now)

bower-rails

pros:

• Uses the mainline bower code and repositories
• Creates logical separation between assets and other gems
• Implements Bowerfile, a DSL that mimics the Gemfile format

cons:

• Requires more setup time, since it requires node environment setup
• Pushing to Heroku requires using multi-buildback

Suggestion

Add support for Bowerfile and merge the two efforts into creating a common file format.

What will this do?

• Remove need for hacky ' gem "rails-assets-someone--some-package" ' syntax
• Make it easy to easily switch between different asset management tools which can be proposed to be standardized
• The folks at 42dev has done the hard work of getting started. Here is the conversation that led to the Bowerfile name: Naming issue in DSL rharriso/bower-rails#29

And check out it's current documentation. https://github.com/42dev/bower-rails#ruby-dsl-configuration

Thoughts?

cc: @SergeyKishenin @rharriso

[ghost]

I agree with this, for the seperation of assets and gems is a must, and bowerfile is actually quite nice 👍 from me

[SergeyKishenin]

I haven't tried rails-assets yet, but I find your idea very cool! 👍 for flexibility in asset management.

[sheerun]

Hi, thanks for this issue :)

I like the idea of joining forces. I read all the source and issues of bower-rails, and I see few issues that need to be resolved first:

• Both bower and user solution lacks Bowerfile.lock that prevents different versions of assets to be compiled in production. Currently different versions can be installed even when re-deploying. Also see Prereleases in semver ranges with Git endpoints aren't ignored bower/bower#1017 which is not yet released (we use patched version in rails-assets production).
• Your solution to builds breaking during deploys because of missing bower executable (ERR 127) is to disable installation by resolve_before_precompile and include assets in repository. I think even allowing including external assets in repository is design mistake.
• You're cleaning non-main assets by default. Many bower components are missing critical entries in main, or act as collection of libraries, so no there's no main entry on purpose. See How to manage missing "main" in bower.json? #3
• You don't create aliases for main files as we do, so require underscore/underscore can be written as require underscore
• You prefer, and recommend installing assets to vendor directory while I think half-compiled assets (not yet post-processed by sprockets) are temporary in nature and should be placed in tmp, even in development.
• By using assets_path in DSL you assume every bower component contains only one type of asset, while in reality many components contain all sorts of assets (css, js, fonts, images). If rails-assets implemented DSL, the assets_path would not be part of it. We split assets to different types automatically (most importantly: javascripts, stylesheets, images, fonts) and put them in standard locations.

What I don't like about rails-assets:

• It's centralized. If rails-assets.org goes down, every application using it cannot be deployed.
• It doesn't support custom branches / master branches. Only tags are builded.
• Declaring dependencies in Gemfile is cumbersome. The path, git, github doesn't work at all. Gem names are too long (rails-assets prefix). I don't think using bundler dependency tree and rails-assets is necessary because neither bower components will use rubygems as dependencies, nor rubygems will declare rails-assets as dependencies, because of security.

For long time I'm planning extracting conversion logic to gem (#55), but sincerely we don't have enough human resources. Since beginning of next month I'm reducing my daily job time to have more time on open source projects so there should be more progress.

As far as sole format of Bowerfile is concerned, I think it should be exactly the same as Gemfile, but with gem replaced with asset. Because of issues I listed I think assets_path is out of the scope.

[sheerun]

If you'd like to allow committing modified repositories under vendor/assets I'd suggest supporting syntax like:

asset 'underscore', path: 'vendor/underscore'

[webhat]

I agree with @sheerun that the centralization of RA.org is a pitfall, I have had a couple of builds fail in CI due to the fact that RA.org was slow or unreachable.

[sheerun]

Both teams agreed to join forces, and create solution sharing best parts of both worlds 🍰

If anyone is interested in pushing things forward, please email me at [email protected]

[webhat]

👍

[chrisnicola]

Seconded for support for pointing to project branches. This is quite commonly my workflow where I'm actually working off a fork of a project and not the project itself because I've contributed bug fixes or features that I need right now.

[brodock]

If the merged solution doesn't require to install bower on production server I think it is good. What I like about rails-assets is that I don't need to install the full node stack to have bower stuff in my ruby project.

[sheerun]

This feature won't be implemented anytime soon. Maybe for new standalone gem, but not this project.