Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A solution to assets management in Rails

rails-assets.org

Post reply on HN
Print view View original

21–30 of 35 posts

Re: A solution to assets management in Rails

#21

Post by gkop »

michaelmior wrote: post #18
gkop wrote: post #17

Earlier quoted context omitted.

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.

Re: A solution to assets management in Rails

#23

Post by adamtj »

ffn wrote: post #14

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?

Re: A solution to assets management in Rails

#24

Post by nixme »

gkop wrote: post #16
twerquie wrote: post #5

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.

Re: A solution to assets management in Rails

#26

Post by michaelmior »

gkop wrote: post #21
michaelmior wrote: post #18

Earlier quoted context omitted.

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…

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

Re: A solution to assets management in Rails

#27

Post by sheerun »

twerquie wrote: post #5

What's wrong with just using Bower?

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.

Re: A solution to assets management in Rails

#28

Post by sheerun »

adamtj wrote: post #23
ffn wrote: post #14

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.

Re: A solution to assets management in Rails

#29

Post by Smudge »

michaelmior wrote: post #26
gkop wrote: post #21

Earlier quoted context omitted.

$ 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…

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?

Re: A solution to assets management in Rails

#30

Post by Smudge »

ulisesrmzroche wrote: post #20
Smudge wrote: post #13

Earlier quoted context omitted.

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.

Post reply on HN