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

11–20 of 35 posts

Re: A solution to assets management in Rails

#11

Post by Smudge »

joevandyk wrote: post #2

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.

Re: A solution to assets management in Rails

#13

Post by Smudge »

chrisweekly wrote: post #10
munificent wrote: post #9

Earlier quoted context omitted.

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.

Re: A solution to assets management in Rails

#16

Post by gkop »

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.

Re: A solution to assets management in Rails

#17

Post by gkop »

chrisweekly wrote: post #10
munificent wrote: post #9

Earlier quoted context omitted.

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

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

Re: A solution to assets management in Rails

#18

Post by michaelmior »

gkop wrote: post #17
chrisweekly wrote: post #10

Earlier quoted context omitted.

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

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.

Re: A solution to assets management in Rails

#20

Post by ulisesrmzroche »

Smudge wrote: post #13
chrisweekly wrote: post #10

Earlier quoted context omitted.

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.
Post reply on HN