Developer's tips for using Composer

Composer is a great way to manage code dependencies from various repositories for your website. However it can get a bit messy when trying prepare a development site for a production deployment, or simply trying to clone an existing site. Here are a few tips for managing the process.

Tie down the versions you need

Running a "composer update" will pull all the latest code from all remote repositories. This is too risky on a production system and causes headaches in development because it often introduces unforeseen problems, leaving a trail of knots to untangle. To avoid updates to specific repositories, tie each repository to a version. This can be done using hashes for absolute precision. Like this:

"vendor/package": "dev-master#5bf81665d7926041400d177c794d2552d46977ca"

Tying to a hash is a totally rigid solution. If you're prepared to allow minor releases (usually just bug fixes you actually need) into your system then use a reference to the repository's tags instead. To tie to a specific tagged version, you use:

"vendor/package": "1.0.1"

To tie to a version that can be updated with minor fixes, you use instead:

"vendor/package": "1.0.*"

This allows a minor update to be included, such as 1.0.2, but it will not upgrade to 1.1.0, as that might have some major changes that cause compatibility issues (new bugs) or user confusion (new features).

Update or Require only the things you want

There are times when you may want to update some, but not all repositories. And there are times when you want to add new repositories. But don't rush to the composer.json file and tediously edit the JavaScript Object Notation with its bafflingly unorderable markup or unforgiving syntax. Simply add the repository using the command line. You can even pick a version. For updates you can even use wildcards. Like this:

composer update "vendor/package*:1.0.*"

This updates the composer.json file for you and updates any packages that match the wildcards.


When cloning from a production site, you want the exact same repositories regardless of the versioning scheme in composer.json. It's a horrid task to track down the current hashed version of each repository, composer won't help you here. Instead just grab a copy of the production site's composer.lock file and run a "composer install". It will install the exact same repository versions as installed on the production system, ignoring the json file. Alternatively you might include the lock file in your project repository so developers can stay in sync and production can be easily updated when deployed.

When you're stuck, pick the lock

Sometimes composer can get stuck because remote repositories have changed. For example, an url has changed or a domain has a new password requirement. In these situations, the composer.lock file can be carefully edited to include new details. Once corrected, run "composer install" to check that the lock file is ok.

Read the manual

Finally, when all else fails just go and read their documentation like a normal person would.

Add Your Comment

Comments (1)

Michael Caruana 23/02/2018 10:30am

I've also found "composer show --latest" is very useful. It lists all the installed packages & their versions, along with the latest available. Green items are up-to-date, red items can be upgraded, and yellow items mean newer versions exist but may not be compatible.

Subscribe to our mailing list to receive exclusive offers, free resources and more!