A solution to assets management in Rails • Hacker News Board

Re: A solution to assets management in Rails

#31

Post by ulisesrmzroche » Tue, Jun 03, 2014, 10:04 PM UTC

Smudge wrote: post #30

ulisesrmzroche wrote: post #20

Earlier quoted context omitted.

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

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

Re: A solution to assets management in Rails

#32

Post by michaelmior » Tue, Jun 03, 2014, 10:27 PM UTC

Smudge wrote: post #29

michaelmior wrote: post #26

Earlier quoted context omitted.

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

I don't recall making that claim.

Re: A solution to assets management in Rails

#33

Post by Smudge » Thu, Jun 05, 2014, 7:05 PM UTC

ulisesrmzroche wrote: post #31

Smudge wrote: post #30

Earlier quoted context omitted.

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

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.

Re: A solution to assets management in Rails

#34

Post by Smudge » Thu, Jun 05, 2014, 7:07 PM UTC

michaelmior wrote: post #32

Smudge wrote: post #29

Earlier quoted context omitted.

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

I don't recall making that claim.

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

Re: A solution to assets management in Rails

#35

Post by chrisweekly » Fri, Jun 13, 2014, 6:34 PM UTC

Smudge wrote: post #30

ulisesrmzroche wrote: post #20

Earlier quoted context omitted.

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

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