Skip navigation

I have been working on a project which used composer to manage dependencies. If you are a PHP developer and do not know about it, I think you
should learn about it. If you happen to worry about the combination in the topic, that means you are already using composer. Great.

In a project I was working on at work was using composer and composer.phar was added to the version control (we use git). Composer.phar is a binary file that would change sometimes when you run

php composer.phar self-update

I didn’t like the idea of having a binary file in version call that would occasionally require a pointless commits in the history. So I went reading about what’s the right thing to do. It was bit of a messy subject but finally I decided that there is no point of adding composer.phar to version control.

Also I found that composer.lock should be in version control (which was not in the project I mentioned). So here it is right from the horse’s mouth.

Commit your application’s composer.lock (along with composer.json) into version control.

This is important because the install command checks if a lock file is present, and if it is, it downloads the versions specified there (regardless of what composer.json says).

So you add composer.lock to version control but keep composer.phar out of it. But what about when you want to use composer.phar? You just get it with

wget -O - | php

Maybe add the instructions to the project’s README file. Also add it to .gitignore to avoid accidents from colleagues who do ‘git add .’

So if you were losing sleep over this, I think now you know what to do.


  1. I found your post when searching the same answer.
    Two years has passed since your post and I still didn’t find any straight answer to this question from the documentation. Probably it doesn’t matter as the code is stable enough but just to add different view to this –

    Coming from the Java world – there is Gradle build system and there one is encouraged to create a Gradle wrapper (basically the same thing as composer.phar) and commit it to the vcs. The idea behind this is that if composer.phar (or Gradle build tool) has a defect then different developers might end up having different versions of composer.phar and due to this fact the dependencies might end up to be different on different developers machines. To avoid this risk – everybody is having the same composer.phar taken from version control system.

    But again – the chache of this ever happening is quite low so I think either way is fine just there might be some point in committing it to repo after all.

  2. Oh thank you !!! My boss puzzled me with a bunch of questions related to this matter and thanks goes all to you. I have looked all over for these info Click

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: