4 ms·

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 increa

by 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.
        ulisesrmzroche 12y ago
        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_modules-folder-into-git https://www.npmjs.org/doc/faq.html#Should-I-check-my-node_mo...
        Smudge 12y ago
        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.
        chrisweekly 12y ago
        "...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....
  - gkop 12y ago
    How do you deal with version-control noise when updating committed assets?
    - michaelmior 12y ago
      Just have a separate commit for these. Not really much different from having a commit which updates bower.json or a Gemfile.
      - gkop 12y ago
        $ 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.
        michaelmior 12y ago
        Sure, if you read through the entire diff it's a lot noisier, but it's still one commit.
        Smudge 12y ago
        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?
        michaelmior 12y ago

by danaw 12y ago

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.
      - ulisesrmzroche 12y ago
        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_modules-folder-into-git https://www.npmjs.org/doc/faq.html#Should-I-check-my-node_mo...
        Smudge 12y ago
        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.
      - chrisweekly 12y ago
        "...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....
- gkop 12y ago
  How do you deal with version-control noise when updating committed assets?
  - michaelmior 12y ago
    Just have a separate commit for these. Not really much different from having a commit which updates bower.json or a Gemfile.
    - gkop 12y ago
      $ 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.
      - michaelmior 12y ago
        Sure, if you read through the entire diff it's a lot noisier, but it's still one commit.
        Smudge 12y ago
        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?
        michaelmior 12y ago