How to manage your application setup with Composer

Composer is a dependency management tool for PHP based projects. It allows you to declare, install, and then manage all of your dependencies in your project.

Right, so you can manage the libraries that your project requires in order to work. But is that all you can really do with Composer? Definitely not! In fact, I believe this is a very small part of Composer and its possibilities. In this article, I’ll try to show you how Composer can be used for performing more complex tasks in PHP based projects.

Outline

In most cases, Composer is being used to only manage dependencies in a single project. It makes updating or downgrading libraries as easy as editing a single line in a file and running a console (terminal) command. But what happens if you consider your main project as a package as well? Having all the elements of a complete application that are managed under Composer may provide you with outstanding possibilities that will allow you to automate the setup and maintenance of your project.

For example, the fact that it can be instantly setup on any machine is surely a significant advantage. No matter if you are setting up a local environment, staging or a demo instance, just run the Composer task and wait for the application to build.

Of course, this process does have a couple of requirements, which will be pointed out in the sections below. Regardless, I’m convinced that in many cases, the effort taken in preparing your app to be maintained like this will pay off rather quickly. Mainly by allowing you to easily and smoothly manage your project.

Base

During this series of articles, I will often make reference to the root composer.json file and its content. As a matter of fact, it is the most important part because here we define almost everything. The important thing to remember is that in these cases I mean the main composer file, which should be located in your_app/build/ directory. This is where we want to keep only things affecting the ‘build’ result. Actual working files should be located elsewhere, so files don’t get mixed up during the application’s lifecycle. If you manage your application with Composer, it might save you time – time that would otherwise be spent on maintaining and managing the application.

Also, please note that if at any time something is unclear, simply refer to the Composer schema documentation for more in-depth insights and explanations.

Basic usage

Now that we know what we’re aiming to do, we can start working. The first and easiest thing that needs to be done is to simply manage the currently deployed version of your app with Composer.
The important thing to understand is how Composer resolves the sources of the packages. Well, there’s a library that lists the resources for many packages and libraries. It’s available at https://packagist.org. It’s both a default and fallback source for package look ups when executing a Composer command. Luckily, you can define your own package’s sources.

Therefore, you can tell Composer to use your own, even private, GIT repository to look for packages to install. The most basic piece of the composer.json file would look like this:

       {
          "type": "vcs",
          "url": "https://github.com/{UserName}/{Repo}"
 }

For a more detailed synopsis, please refer to the original Composer documentation.

Now that we have the custom package source defined, nothing is stopping us from creating a composer.json file in the root of your repository. This file can actually be very short. You just need to give the Composer enough information to resolve, if this is the package you currently want to install. A sample composer.json file could look like this:

{

"name": "vendor/app",

"type": "application",

"description": "Short description here",

"keywords": ["keyword","fancy keyword"],

"homepage": "http://myproject.com",

"license": "GPL-3.0+",

"authors": [

        {

                  "name": "Company",

                  "email": "hello@company.com",

                  "homepage": "http://company.com"

         }

],

"require": {

         "php": ">=5.3.2"

},

}

One thing to remember is that the package name should match the vendor/package naming convention. Also, the package name specified here is the one that should be used in our root composer.json file. Now, just push this file to your repository. Also, to make your life easier, you can use semantic versioning in your project. Adhering to these guidelines overtime will allow you to control the project better.

Having our app prepared this way allows us to perform code deployment.
To add this as a dependency in our root json file, simply add

"require": {

     	“vendor/app” : “0.1.0”

}

Then, in the event that you have Composer installed locally, simply run

$ php composer.phar install

This command should result in downloading the above package in this specific version, along with its dependencies. Viola! Deploying your code easily into a server is as simple as that. The only requirement is to upload the composer.json file and the Composer itself. From this moment on, to update your codebase simply change the version in composer.json and run

$ php composer.phar update

Quite easy, isn’t it? No GIT skills required at all.

Of course, in many cases, repositories are private and require additional access permissions. In such cases, you can use your private key validation with a SSH protocol, or simply type in your credentials during the install and update phases. The most important thing to keep in mind is that when you type in your credentials, you’ll need to maintain caution as they could be spoofed by hidden server software that you are unaware of. Also, retrieved data is serialized and stored in the Composer cache for further usage, so be really careful about how you proceed with the credentials. This matter will be discussed in another article within this series.

Summary

This article didn’t quite show the whole power of Composer oriented application management. However, once you start adding further libraries to your application and other self-hosted components, it’ll slowly start to become easier to manage and deploy on any machine.
No need to remember a version or a repository URL, simply copy the composer.json file to the target destination and install it.

By default, all the packages will be downloaded into the same directory (your_app/vendor/). After seeing that, one obvious question that you might be asking yourself could be – what is the use of an application that is installed among other libraries? Customizing install destination paths requires a longer introduction, and it will be described in the next article. So stay tuned!