A solution to assets management in Rails | Hacker News Reader

A solution to assets management in Rails

rails-assets.org

62 pointslfxx34 comments

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.

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.

How do you lock your bower dependencies then?

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

Why exactly should you be willing to commit them? There are certainly ways to lock your versions while still vendoring the files on deploy.

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.

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.

"...you can point to a particular commit hash in that library's repo"

Riiight... because Github has never gone down and never will. ??? How would you propose to mitigate the risk of external repos being unavailable?

I'm writing from the perspective of real-world enterprise web application management best practices. This is not "failure to understand how dependency resolution works", it is "real world experience". Honestly, I don't think I've ever encountered someone with meaningful experience who hasn't come to the same conclusion. There's a first time for everything, I guess....

Yeah, sure buddy. I think you're just kind of a noob and are really not getting the whole picture yet. Google around for the debate, it's been thrown around for ages, or start here maybe.

https://www.npmjs.org/doc/faq.html#Should-I-check-my-node_mo...

I didn't realize we were talking about node here, so I suppose you're right. I'm a noob at node. Which of course is ages old. Way older than any of those other technologies I've been using for the past 15 years or so.

Sarcasm aside, I have to say I'm surprised at npm's best practices, but whatever. Personally, I'd rather not make my line count graph explode every time I add or remove a dependency. I still firmly believe that source control is not the only way to reliably vendor files.

How do you deal with version-control noise when updating committed assets?

Just have a separate commit for these. Not really much different from having a commit which updates bower.json or a Gemfile.

  $ bower install angular > /dev/null
  $ find bower_components/angular/* | xargs wc -l
     18 bower_components/angular/angular-csp.css
  21463 bower_components/angular/angular.js
    210 bower_components/angular/angular.min.js
    141 bower_components/angular/angular.min.js.gzip
      8 bower_components/angular/angular.min.js.map
      7 bower_components/angular/bower.json
     48 bower_components/angular/README.md
  21895 total

That's 21893 more lines in this diff than the equivalent when using rails-assets.

Sure, if you read through the entire diff it's a lot noisier, but it's still one commit.

You claim that it's important to guarantee, with 100% certainty, that the version of a library you're getting in production is the one you expect. But then you say it's not necessary to read through the entire diff if you check that library into source control. What if someone were to make a commit called "Updating jQuery to 2.1" but injected malicious code? Wouldn't that require another way of making sure your vendored files are from a trusted source? Would you still need to check them into source control?

I don't recall making that claim.

You're right -- my mistake. I mistook your comment for someone else's.

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".

Fanstatic is pretty close: http://www.fanstatic.org/

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

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?

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.

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?

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.

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.

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

What's wrong with just using Bower?

Check out 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.

You know sprockets includes bower support. Just add the path.

Among other things, Bower lacks the equivalent of Gemfile.lock or npm-shrinkwrap.json.

So you can't get reliably repeatable installs.

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.

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.

(the wrong) solution to asset management in Rails

That's pretty nifty.

Reply on news.ycombinator.com