codebright

The Primers 31
1 Loading composer repositories with package information
2 Installing dependencies
3
4 - Installing xmen/beast (1.1.0)
5 Cloning bc0e1f0c34343347a38c232132132121a2fd53e94
6
7 Writing lock file
8 Generating autoload files
Now xmen/beast has been installed and we can use it right away. Smashing!
You may have noticed the following line in the output from the composer install command.
1 Writing lock file
You might also have noticed that Composer has created a file called composer.lock at the root of
your application. What’s that for I hear you cry?
The composer.lock file contains the information about your package at the time that the last
composer install or composer update was performed. It also contains a list of the *exact version
of each dependency that has been installed.
Why is that? It’s simple. Whenever you use composer install when a composer.lock file is present
in the directory, it will use the versions contained within the file instead of pulling down fresh
versions of each dependency.
This means that if you version your composer.lock file along with your application source (and
I highly recommend this), when you deploy to your production environment it will be using the
exact same versions of dependencies that have been tried and tested in your local development
environment. This means you can be sure that Composer won’t install any dependency versions
that might break your application.
Note that you should never edit the composer.lock file manually.
While we are on the topic of dependency versions, why not find out about updating them? For
example if we had the following requirement in our composer.json file.
1 "xmen/gambit": "1.0.*"
Composer might install version 1.0.0 for us. However, what if the package was updated to 1.0.1 a
few days later?
Well, we can use the composer update command to update all of our dependencies to their latest
versions. Let’s have a look at the output.