Dayle Rees has a post to his site help to demystify the composer.lock file for the Composer users out there - what it's for, how it works and why you may or may not want to have it in version control.

Everywhere that I go, conference, the supermarket, the dentist, building sites, people always ask me about the Composer lock file. It's a mystery that seems to cause confusion all across the globe. Well, boys and girls, I'm here today to de-mystify the lock file once and for all.

He starts with a new project and some simple dependencies (three of them), two with specific versions defined and one with a wildcard. Once a composer install is run, the packages are downloaded and the composer.lock file is created. He talks about the contents of the lock file and how they relate to the version of the library Composer has installed, the exact version to be precise. He then gets to the question many wonder about the lock file - should I commit it to my version control system? He suggests that, if you need exact versions installed, then yes. This helps keep versions the same across the board of a team and ensures other people working with the library are using compatible library versions. He ends the post talking about how to use the lock file (install vs update) and what changes could be made in one versus the other.

In a new post to the Engine Yard blog Nils Adermann provides an overview of using Composer with continuous integration, its role in the overall process and some good practices to follow in its use.

Continous Integration (CI) is the practice of continuously (and automatically) testing every change a developer makes. So automated tests become an integral part of the development process providing direct feedback on changes made. [...] Davey Shafik's article on Composer's Lock File explains the typical usage of composer install and update. The key takeaway is that developers should run composer update manually to explicitly update individual dependencies while composer install should be used in automated processes. This principle includes automated test environments.

He points out that using the lock file method reproduces the vendor directory exactly as it is in production and what it means for failures in your automated tests. He also talks about methods to improve the build performance to reduce time spent during the generation of the environment, including the use of the Composer cache data. He includes a few flags you can pass to Composer to reduce not only the libraries it installs but also how it fetches their contents.

In an interesting thread on the /r/php subreddit on Reddit.com, a user noticed that Google is indexing Composer files that are in the document root of PHP applications. These files, like "composer.json" and "composer.lock" can provide detailed information about which packages and libraries are in use in the application (information disclosure).

The problem is that these files are placed in the web root of the application and not in a folder one level up, a recommended practice. The post links to a Google search that shows an example of current sites with the issue.

Another comment in the same post also reminds users not to have things like their ".git" files in the document root either as they can provide valuable information to would be attackers about your application's code. Things can be done to prevent direct access to these files in the web server configuration but it's far better to restructure the application to have them in a parent directory of the actual web root.

In his latest post Phil Sturgeon talks about a point that's been argued on both sides of the Composer users out there - whether or not to commit the "composer.lock" file. Phil talks some about it in his article and suggests that you should commit it for applications but not for components.

If you and your employees are a little vague with your composer.json specifications and you don't have a composer.lock then you can end up on different versions between you. Theoretically, if component developers are using SemVer and you're being careful then you should be fine, but keeping your lock in version control will make sure that the same version is on your dev teams computers. This will happen every time you run $ composer install. If you are on Heroku or EngineYard then this will be used for the deployment of your production components as a built in hook, which is awesome.

He mentions an article from Davey Shafik, this being his reaction to it. He suggests, though, that an absolute of "always commit for components" may be too much and could potentially cause other problems. He points out that since the "composer.lock" handling is local to the directory, you can hit up against version requirement issues between them in your application as a whole. He wonders "how strict is too strict" when defining dependencies and some things to think about (like your users) when making the choice to upgrade the libraries you use.