Composer – Dependency package management for PHP!

A new week and a new blog. December is here and along with it the scent of the soon to come Christmas Holidays: gifts, lights and the cossyness of a fat armchair where I can rest alone with my laptop programming or improving my graphic design skills deep into the night.

What a life! 🙂

But before further day dreaming, let me tell you the story of Composer, a tool that eases package dependency management in PHP.

Being more or less a cousin of the npm for Node or Ruby´s Bundler, this tool has been around for some years now, yet has not lost the utility it had proven over its time span.

Then and now

Back in the days, were you to work with a third-party package, you had to firstly go through with manually downloading and including the package in your PHP application. Administrating it was not a thing for the weak heartened either, as you had to keep running periodic manual updates every now and then.

Things have gotten however more straightforward. Modern PHP frameworks nowadays consist of small packages that are pulled and assembled by Composer for your application. These core packages depend on each other in order for the framework (and/or your application) to function properly.

Moreover, there is also the option to add extra packages to your application and choose between specific functionalities that can decrease the development time of your project.

Using Composer

There are a couple of steps you should have in mind when working with Composer. Here is a short guide that can give you some starting points I myself find useful:

1. Define the package and versions you wish to have pulled;
2. Include the package in your application via the “composer.json” file in the root;
3. Run “composer install” from your terminal. This will trigger composer to download and install the packages you have defined. They will next be placed in a “vendor” directory inside your project;
4. In your code, “require” the “vendor/autoload.php” file that comes with Composer. This will autoload the packages and the classes will soon be available in your project;
5. Lastly, instantiate the package classes. In most modern PHP frameworks, such as Laravel, there will be no need for you to include this file as it is already autoloaded.

Composer.lock – The Dev Teams best friend!

When you run the command “composer update”, a lock file is generated. This file can really be the development team´s best friend.

Why may you ask? It helps to ensure that everyone in the team uses the same versions of the packages when developing applications.

This file should be committed to the application repository as soon as possible.

The point of the lock file previously mentioned is to guarantee that everyone uses the exact version for each package. Even small updates, such as bug-fixes, might sometimes generate bugs with other dependencies. So be smart and oblige your team to use only “composer install” as it ensures package versions defined in the lock file are the solely items being pulled.

If you on the other hand use “composer update”, it will override the lock file and download all new versions of the packages regardless of what has already been defined in the lock file.

To sum up, consider the lock file as a safety device for your team as long as you are concerned with code breakage.

So far so good. But how does Composer keep track of the characteristics of these packages? For example, how does it detect the new from the old?
Well, basically it conquers this task with the help of Semantic Versioning (SemVer).

Semantic Versioning (SemVer) explained

The main advantage of Semantic Versioning (SemVer) is that it homogenizes the different ways in which developers version their packages by allowing them to use one unified standard for version formatting instead of different ones.
Have a look at the picture below:

Major versions are updates most often subject to “breaking”. Simply put, these versions have a high chance of breaking your application once they are pulled down from the repository. Hence, to get these versions working properly, you will have to rewrite your code.

Minor versions add extra functionality or tweaks to the current code, however they should not break your current code.

Patch versions are small updates that fix security related issues or act as “bug-fixes” in the package code. These ones are the most common updates.

Pre-release versions handle Alpha, Beta and release candidates. Pre/release versions should not be considered Stable versions thus must be treated as such.

A common practice is to have minor and/or major versions locked within a version range. This will allow only for minor updates or bug fixes.

“v1.*” or “v1.3.*”.

Most repositories have a “dev-master” branch, which pretty much is the most frequently updated code: the so called “nightly” builds, which has not yet been tested. I recommend you never use this branch for any production intended code.

Furthermore, running Composer should always first and foremost be done on a development or staging environment in order to test the application before updates are rolled out on your production servers.

Well, my friends, that was it for today! Feel free to comment and share! Don’t forget to join in for the next week´s blog! 🙂