Estimated reading time: 11 minutes
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.
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:
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:
To tie to a version that can be updated with minor fixes, you use instead:
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).
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.
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.
Finally, when all else fails just go and read their documentation like a normal person would.