3

In doing research on whether Node's node_modules should be checked into your version control repository, the most recent consensus seems to be that you should include it for applications you deploy.

Sources:

In reading these arguments, it lead me to question whether Composer's /vendors directory should also be checked into version control. Composer's documentation suggests that you don't:

Should I commit the dependencies in my vendor directory?

The general recommendation is no. The vendor directory [...] should be added to .gitignore/svn:ignore/etc.

The best practice is to then have all the developers use Composer to install the dependencies. Similarly, the build server, CI, deployment tools etc should be adapted to run Composer as part of their project bootstrapping.

While it can be tempting to commit it in some environment, it leads to a few problems:

  • Large VCS repository size and diffs when you update code.
  • Duplication of the history of all your dependencies in your own VCS. [...]

Contrasting that argument is this one (source):

Doesn’t checking in node_modules create a lot of noise in the source tree that isn’t related to my app?

No, you’re wrong, this code is used by your app, it’s part of your app, pretending it’s not will get you in to trouble. You depend on other people’s code and they are just as likely to write new bugs as you are, probably more so. Checking all of that code in to source control gives you a way to audit every line that ever changed in your application. It allows you to use $ git bisect locally and be ensured that it’s the same as in production and that every machine in production is identical. No more tracking down unknown changes in dependencies, all the changes, in every line, are viewable in source control.

In summary, the question is this: Why would one gitignore (i.e. not version control) node_modules but not do the same for Composer's vendor/ directory?

Community
  • 1
  • 1
sbuck
  • 1,846
  • 4
  • 24
  • 40

3 Answers3

1

The reason to commit external dependencies is

  • it's easier to deploy with git pull
  • the code used is directly included in the commit anyone checks out

Arguments against this are

  • Git is no deployment tool
  • all dependency managers do have a way to make exactly sure the code used can be fetched

I don't know anything about npm, but for Composer that last point is implemented by committing composer.lock.

I don't think the "audit code" argument is a valid one in every case. If you do write software that get's audited by itself, and subsequently needs all libraries to be audited, then probably all code changes need to be conserved. This isn't true for the general case.

git bisect works still as well with a committed composer.lock. It does require installing the dependencies with every bisect step, but this is just one simple step, probably already done in the automatic test suite run.

The last thing to worry about is when used packages go offline. This really is more of a problem with Composer, because there is no central hosting of the downloadable releases (npm probably does this). If this is a problem, either commit the code (and try to figure out how to update that missing package in the future), or setup an instance of Satis to create a local copy of the code you use.

Sven
  • 69,403
  • 10
  • 107
  • 109
0

Putting all your modules in you VCS makes it really heavy to download or upload. For example, I work on two node.js projects and the total node_modules directories size is between 250MB and 500MB whereas the whole code with assets is generally less than 40MB. Every Node.js developer likes Node lightness, so the code must stay easy to download and share.

For the second point, an alternative to avoid regressions is to be more restrictive in your package.json dependencies versions. You will find more information here.

Finally the best argument is to take a look on the famous modules everybody know :

  • express ignores node_modules
  • mocha ignores node_modules
  • q ignores node_modules
  • ...
Community
  • 1
  • 1
jsebfranck
  • 704
  • 2
  • 9
  • 18
0

The more I research this the more I'm starting to think that there is no one correct answer to this, just different opinions as well as pros and cons of each method.

This blog, looking from the context of Bower, does a good job of weighing the pros and cons of each: http://addyosmani.com/blog/checking-in-front-end-dependencies/.

In short: At least for right now, weigh the pros and cons and decide what best fits your situation.

sbuck
  • 1,846
  • 4
  • 24
  • 40