I’m not sure who started this pattern so I can’t really refer back but if you know please comment below and I will update the post. I’m sure all of you have heard that you should not check in anything that can be generated to Source control. It’s long been a common pattern. However, lately I have been checking in my dependencies into my source control and it works really well for small to medium project. Here’s why.
Isolate you from any network failures.
I know you might say that it rarely happens to me so why should I care about this. I hear you. It rarely happens to me as well but when it did happen I got really frustrated. Especially, when your CI failed without any reason and you found out that one of your dependencies doesn’t get downloaded properly.
This frustrates me the most and it’s one of the reasons why I started doing this. More than often that my CI failed and it’s because of dependencies didn’t get resolved or compiled properly and people just kept running it over and over again. To eliminate this problem and let CI just run the tests save me a lot of pulling my hair time.
Check out and Go!
This pattern I have learnt while I was working with ThoughtWorks that it’s so frustrated when you are joining a project and you spend almost half a day just to get your machine up and running and run the build script to download all the dependencies. I believed that’s one of the reasons why Chef and Puppet exist. It’s so easy when you checkout a project from your source control and you can start coding right away or even run all the tests.
I also have this support from my friend
@noppanit I've been a fan of that technique for a long time now.
— Scott Myц (@ScottMuc) March 22, 2015
Srini also pointed out that you shouldn’t do that for internal project dependencies
— Srinivasan Raguraman (@sragu) March 22, 2015
I know people might argue that it doesn’t really work for big project because of the size of the repository. That’s why I mention small to medium project. It works really well with small projects. Another point to mention is that every developer might have different environment for example, Windows VS Linux which node_modules might not work for both environments. I solve that problem by using Vagrant so everybody has the same environment.