Menu
Bower docs says
N.B. If you aren't authoring a package that is intended to be consumed by others (e.g., you're building a web app), you should always check installed packages into source control.
Does anyone have a good answer to why?
If I am making a web app I don't want my repo cluttered with updates in version of library X.
I just want to update bower.json dependencies. I would think most projects will have a build step or similar, for instance with grunt. The build step would make sure to call bower install/update before building, so that those files are present for concat/minification etc. Or even a plain copy to some dist folder.
Am I missing something?
249
Bower provides hooks to facilitate using packages in your tools and workflows. Bower is optimized for the front-end. If multiple packages depend on a package - jQuery for example - Bower will download jQuery just once. This is known as a flat dependency graph and it helps reduce page load.
Bower is a package manager for client-side libraries and components that contain HTML, CSS, JavaScript, fonts, image files, and so on. You can install, locate, upgrade, and remove Bower packages without leaving WebStorm, on the dedicated Bower page or from the command line in the built-in terminal.
Bower has been deprecated by its creatorsAfter a long and heated debate on Github, the creators of Bower decided it does not add value to the current web development stack and should be discontinued.
json file which defines some information about the projects as well as a list of dependencies. The bower. json file is actually used to define a Bower package, so in effect you're creating your own package that contains all of the dependencies for your application.
It's to lock down your dependencies so to prevent a bad dependency from breaking your app or the remote being down preventing deployment. This could happen even though you have a build step, since you probably don't thoroughly test on every build, and automated tests don't catch everything, especially not visual regressions. Also multiple developers might have different versions of a dependency. By having the dependencies committed you ensure everyone stays on the same version. I also find viewing the diff is a good way to ensure nothing malicious was introduced in the dependency tree.
In the Node world npm shrinkwrap partially solves this, but doesn't yet do checksum matching. Bower currently have an open ticket to implement the same.
You can read more about it in this blog post: Checking in front-end dependencies
93
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
