27

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?

Martin Hansen
  • 5,154
  • 3
  • 32
  • 53

2 Answers2

28

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

Sindre Sorhus
  • 62,972
  • 39
  • 168
  • 232
  • Yeah I guess I thought I could use 1.2.3 instead of ~1.2.3 or similar. (Or even that is ok if I trust the library to use semver) But I guess if library X have in it's bower.json a depedency to library Y and uses >=2.3.4 or similar then I'm in trouble. Will be looking forward to a shrinkwrap feature. – Martin Hansen Jun 23 '13 at 10:36
  • 3
    Yes, and locking down versions, even deep, isn't enough since tags and versions can be overriden. That's why `npm shrinkwrap` needs checksum matching of deps and that's what we want in Bower shrinkwrap from the start. – Sindre Sorhus Jun 23 '13 at 10:59
  • This is the same reasoning as for game development. You don't upgrade packages all the time so it makes sense to freeze or "shrinkwrap" them at a particular version to prevent delays in deployment or builds. –  Sep 17 '13 at 19:43
0

This answer is non technical but a practical reason to not check in bower components.

I'd rather recommend bower packages to be locked down in bower.json rather than checking in these packages. Because trust me, you cannot have thousands of file downloading and unpacking in a computer. Slow performing computers have a problem with very large and deep file paths. And in this world of internet, I believe it's always easy to download the packages rather than carrying them around.

It is just a matter of preference. It all comes from experience. I have checked in a project with bower components on Github and it is worse while uploading and downloading. I did it through a relatively new Mac.

Ankit Tanna
  • 1,779
  • 8
  • 32
  • 59