6 ms·

A solution to assets management in Rails

62 points by lfxx 12y ago

joevandyk 12y ago
I don't get this. It's not hard to download a JavaScript or css file and put them in app/assets. What warrants the additional complexity?
- jbverschoor 12y ago
  It becomes a huge mess, and you will not remember which file belongs to which project. All css files and images are in the same and you have no clue which version you are using.
- Smudge 12y ago
  It's not that hard, but do it 50 times, manually managing a complex dependency tree (which jQuery version does this thing need again?), and you'll realize how nice it would be to have a package manager for your client-side dependencies.
jbverschoor 12y ago
TL;DR -> Gem repo which automatically converts Bower packages to gems Awesome! Was looking for something like this. I used to have a "vendorassets" directory where I could sanely manage 3rd party assets. Still a pain in the ass sometimes. Rails-gems are usually out of date and everyone seems to jump the bower-ship.
twerquie 12y ago
What's wrong with just using Bower?
- mcmillion 12y ago
  I guess the idea would be that you could keep everything in your Gemfile. Personally, I'm fine with just using Bower for the front end pieces.
- ef4 12y ago
  Among other things, Bower lacks the equivalent of Gemfile.lock or npm-shrinkwrap.json. So you can't get reliably repeatable installs.
- gkop 12y ago
  Check out http://bower.io/ http://bower.io/ : > Bower is a package manager for the web. It offers a generic, unopinionated solution to the problem of front-end package management, while exposing the package dependency model via an API that can be consumed by a more opinionated build stack. rails-assets is an example of a higher-level, more opinionated stack that adds value on top of bower.
  - nixme 12y ago
    You know sprockets includes bower support. Just add the path.
- sheerun 12y ago
  Rails Assets: - creates manifest files for each component so you can just "require jquery" instead "require jquery/dist/jquery" - splits assets in four categories: javascripts, stylesheets, images, fonts, so you can use sprockets helpers without a problem - replaces relative urls in stylesheets with image-url font-url etc., so assets work out of the box - converts .css files to .scss so you can get advantage of @import in SASS files - you get assets locking with Gemfile.lock, so you can be sure each deploy will look the same. It's not possible yet with bower. And few other sprockets integrations. Unfortunately it's centralized solution but we're working on that.
Bluestrike2 12y ago
That's pretty nifty.
danaw 12y ago
Just set bower to install into vendor/assets and link to those instead in your stylesheets/scripts. No need to add an additional layer of indirection and increasing the length of you Gemfile. Your bower.json should be where this information is stored, not you Gemfile.
- munificent 12y ago
  How do you lock your bower dependencies then?
  - chrisweekly 12y ago
    Bower deps are bound by semver; and if you're willing to commit them (which you should, if your project is a webapp and not a software library) then you can lock them w 100% certainty and control. /$.02
    - Smudge 12y ago
      Why exactly should you be willing to commit them? There are certainly ways to lock your versions while still vendoring the files on deploy.
      - ulisesrmzroche 12y ago
        But the libraries you depend on may not work nicely together, minor versions for them could create breaking bugs in your app, and a ton of other things that can go wrong. The easiest way to put your app at the real working truth (no difference btween dev, prod, etc) is to commit your vendor files.
        Smudge 12y ago
        If you're relying on specific version releases of the libraries, you'll always be vendoring the same files (and if not the deploy should fail). If you are relying on a non-versioned release from a git repo, you can point to a particular commit hash in that library's repo. Neither of these requires checking your app's dependencies directly into its git repo. Source control is not in itself a solution for dependency resolution. Sure, once your dependencies are worked out you can check them in, if you really want them hard-coded, but it shouldn't be necessary. Claiming so is a failure to understand how dependency resolution works -- part of the point of bower, or rubygems, or what have you, is knowing that you'll always get the same versions in all environments.
ffn 12y ago
Oh sweet. Looks like I don't have to put vendor assets code into my git repos anymore. Thanks rails-assets.org
- adamtj 12y ago
  That would tie your ability to deploy your code to the availability of rails-assets.org. How many nines are they promising you and how much are you paying for it?
  - sheerun 12y ago
    You're totally right, we want to decentralize Rails Assets in some way. On other hand we're pretty close to the uptime of GitHub and we're not going anywhere, so I would't worry too much.
PetrolMan 12y ago
This is really neat but my problem with the asset pipeline hasn't been managing library dependencies but the general slowness of the process.
clarkevans 12y ago
Is there an equivalent to this in Python land (I've looked but not seen anything)? It'd be great to have "pip install bower-bootstrap".
- rhizome31 12y ago
  Fanstatic is pretty close: http://www.fanstatic.org/ http://www.fanstatic.org/
kaonashi 12y ago
(the wrong) solution to asset management in Rails

62 points by lfxx 12y ago

I don't get this. It's not hard to download a JavaScript or css file and put them in app/assets. What warrants the additional complexity?

jbverschoor 12y ago
It becomes a huge mess, and you will not remember which file belongs to which project. All css files and images are in the same and you have no clue which version you are using.
Smudge 12y ago
It's not that hard, but do it 50 times, manually managing a complex dependency tree (which jQuery version does this thing need again?), and you'll realize how nice it would be to have a package manager for your client-side dependencies.

jbverschoor 12y ago

TL;DR -> Gem repo which automatically converts Bower packages to gems Awesome! Was looking for something like this. I used to have a "vendorassets" directory where I could sanely manage 3rd party assets. Still a pain in the ass sometimes. Rails-gems are usually out of date and everyone seems to jump the bower-ship.

twerquie 12y ago

What's wrong with just using Bower?

mcmillion 12y ago
I guess the idea would be that you could keep everything in your Gemfile. Personally, I'm fine with just using Bower for the front end pieces.
ef4 12y ago
Among other things, Bower lacks the equivalent of Gemfile.lock or npm-shrinkwrap.json. So you can't get reliably repeatable installs.
gkop 12y ago
Check out http://bower.io/ http://bower.io/ : > Bower is a package manager for the web. It offers a generic, unopinionated solution to the problem of front-end package management, while exposing the package dependency model via an API that can be consumed by a more opinionated build stack. rails-assets is an example of a higher-level, more opinionated stack that adds value on top of bower.
- nixme 12y ago
  You know sprockets includes bower support. Just add the path.
sheerun 12y ago
Rails Assets: - creates manifest files for each component so you can just "require jquery" instead "require jquery/dist/jquery" - splits assets in four categories: javascripts, stylesheets, images, fonts, so you can use sprockets helpers without a problem - replaces relative urls in stylesheets with image-url font-url etc., so assets work out of the box - converts .css files to .scss so you can get advantage of @import in SASS files - you get assets locking with Gemfile.lock, so you can be sure each deploy will look the same. It's not possible yet with bower. And few other sprockets integrations. Unfortunately it's centralized solution but we're working on that.

Bluestrike2 12y ago

That's pretty nifty.

danaw 12y ago

Just set bower to install into vendor/assets and link to those instead in your stylesheets/scripts. No need to add an additional layer of indirection and increasing the length of you Gemfile. Your bower.json should be where this information is stored, not you Gemfile.

munificent 12y ago
How do you lock your bower dependencies then?
- chrisweekly 12y ago
  Bower deps are bound by semver; and if you're willing to commit them (which you should, if your project is a webapp and not a software library) then you can lock them w 100% certainty and control. /$.02
  - Smudge 12y ago
    Why exactly should you be willing to commit them? There are certainly ways to lock your versions while still vendoring the files on deploy.
    - ulisesrmzroche 12y ago
      But the libraries you depend on may not work nicely together, minor versions for them could create breaking bugs in your app, and a ton of other things that can go wrong. The easiest way to put your app at the real working truth (no difference btween dev, prod, etc) is to commit your vendor files.
      - Smudge 12y ago
        If you're relying on specific version releases of the libraries, you'll always be vendoring the same files (and if not the deploy should fail). If you are relying on a non-versioned release from a git repo, you can point to a particular commit hash in that library's repo. Neither of these requires checking your app's dependencies directly into its git repo. Source control is not in itself a solution for dependency resolution. Sure, once your dependencies are worked out you can check them in, if you really want them hard-coded, but it shouldn't be necessary. Claiming so is a failure to understand how dependency resolution works -- part of the point of bower, or rubygems, or what have you, is knowing that you'll always get the same versions in all environments.

ffn 12y ago

Oh sweet. Looks like I don't have to put vendor assets code into my git repos anymore. Thanks rails-assets.org

adamtj 12y ago
That would tie your ability to deploy your code to the availability of rails-assets.org. How many nines are they promising you and how much are you paying for it?
- sheerun 12y ago
  You're totally right, we want to decentralize Rails Assets in some way. On other hand we're pretty close to the uptime of GitHub and we're not going anywhere, so I would't worry too much.

PetrolMan 12y ago

This is really neat but my problem with the asset pipeline hasn't been managing library dependencies but the general slowness of the process.

clarkevans 12y ago

Is there an equivalent to this in Python land (I've looked but not seen anything)? It'd be great to have "pip install bower-bootstrap".

rhizome31 12y ago
Fanstatic is pretty close: http://www.fanstatic.org/ http://www.fanstatic.org/

kaonashi 12y ago

(the wrong) solution to asset management in Rails