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.
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.
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.
> 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.
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.
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
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.
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.
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.
"...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....
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?
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?
34 comments
[ 1.8 ms ] story [ 63.6 ms ] threadIt's not hard to download a JavaScript or css file and put them in app/assets.
What warrants the additional complexity?
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.
So you can't get reliably repeatable installs.
> 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.
- 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.
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.
https://www.npmjs.org/doc/faq.html#Should-I-check-my-node_mo...
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.
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....
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.