What’s in your Composer file?

During the recent Crafting Code Tour, Paul Jones would ask people who was currently using Composer. It was a rare night that more than half an audience raised their hands, meaning that the best invention in the PHP world in the last three years is still not being widely used by everybody. I want to share a bit about how to get started with Composer, and why you should care in the first place.

What is Composer?

Composer is a dependency management tool for your PHP applications. In the old days, you had to copy and paste various components into your project, or use SVN externals, or worse, Git submodules. Lots of people would commit thousands of lines of code into their repositories that they had not written, simply because they needed a particualar library. Composer fixes this problem by giving us a way of grabbing all our dependencies and managing them.

Composer works by reading a composer.json file, using pre-programmed knowledge to find the packages specified, computing their dependencies, and then grabbing everything and setting it up with autoloading. That’s an over-simplifiction, but it works for our purposes. And since we can do this in both dev and production, there’s no need to commit the resulting vendor/ directory to our repository; we can simply re-run the process when we update our application.

Getting Composer

The people who wrote Composer (Jordi Boggiano in particular) have written some very easy-to-use documentation on Composer. They’ve also designed Composer to be equally easy-to-install. Installing Composer is a simple single line:

$ curl -sS https://getcomposer.org/installer | php

That’s all there is to it. The Composer.phar file will download, and you can use it to install your dependencies.

The composer.json file

Composer uses a file called composer.json to know what its dependencies are. This file has very few requirements; all that’s required is that you specify which packages you want. This example is straight out of the documentation:

{
    "require": {
        "monolog/monolog": "1.2.*"
    }
}

By telling it what to require, when we run “php composer.phar update”, it will install monolog for us in the vendor/ directory. It’s that simple.

Finding Packages

Of course, Composer isn’t useful without some packages to go with it. This is where Packagist comes into play. Packagist is a giant list of (most) of the libraries available for PHP. It also has a handy search feature that lets you search the packages you might want, and shows you how many people have installed a particular package (very useful if you’re looking for the “industry standard” on something).

Packagist will also tell you explicitly what line you need in your Composer.json file to include a particular version or development version of a package. This is great, because it removes the guesswork out of including a library.

What’s in your Composer file?

Of course, all developers are creatures of habit. We like to use the same tools over and over again. In one talk I give, the most photographed slide is an (outdated) version of my composer.json file. People are interested in the tools that others use, because they’re interested in finding better tools for the job than they already have. Here’s a copy of my current (as of this writing) composer.json file:

{ 
    "name": "tailwindsllc/modus",
    "description": "The Modus framework, providing basic support for many components of Aura and other libraries.",
    "type": "library",
    "license": "MIT",
	"require": {
	    "php": ">=5.4.0",
    	"aura/session": "1.0.1",
        "aura/intl": "1.0.0",
        "aura/di": "1.1.1",
        "aura/sql" : "1.1.0",
        "aura/router": "1.1.1",
        "aura/view": "1.1.2",
        "aura/http": "1.0.1",
        "aura/web": "1.0.1",
        "aura/cli": "2.0.*@dev",
        "aura/filter": "1.0.0",
        "monolog/monolog": "1.5.0",
        "zendframework/zend-escaper" : "2.2.*",
        "pagerfanta/pagerfanta": "v1.0.1",
        "filp/whoops": "1.0.10",
        "league/flysystem": "dev-master",
        "robmorgan/phinx": "v0.3.2"
	},
    "require-dev": {
        "phpunit/phpunit": "3.7.*",
        "mockery/mockery": "0.9.0"
    },
	"autoload": {
        "psr-4": {
            "Modus\\": "src"
        },
        "psr-0": {
            "Application": "local-src/"
        }
    },
    "bin": [
        "bin/modus"
    ]
}

You can probably see that I’m using many more advanced features of the composer.json configuration file, including telling it how and where to autoload files from, which protocol to use (PSR-0 and PSR-4), and others. All of that is spelled out in the documentation, but none of that is necessary for you to get started with Composer.

Try Composer today

Using Composer shouldn’t require a huge team meeting, approval from your boss, or the buy-in of everyone on the team. It’s so dead simple to use that anyone should be able to pick it up with just two or three commands and use it in the projects you work on. So go, and grab a library you want to use with Composer. Before you know it, you’ll be hooked, and so will the rest of your team.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

Tom Oram (@tomphp) wrote at 8/13/2014 9:40 am:

My require-dev is the most consistent part of my composer.json:

“require-dev”: {
“phing/phing”: “2.*”,
“phpspec/phpspec”: “~2.0”,
“behat/behat”: “3.*”,
“squizlabs/php_codesniffer”: “1.*”,
“tomphp/behat-rest”: “dev-master”,
“robteifi/differencer” : “dev-master”
}

The actual requirements vary from project to project, zendframework/zend-servicemanager does make a fairly regular appearance though.

Scott Arciszewski (@voodooKobra) wrote at 8/13/2014 2:45 pm:

“””
Installing Composer is a simple single line:

$ curl -sS https://getcomposer.org/installer | php

That’s all there is to it.
“””

Has it ever occurred to you that this might be a bad idea? Taking unexamined, unaudited code and pipe it directly to the PHP interpreter. What if I hacked getcomposer.org tonight and added an instruction to write my SSH public key to ~/.ssh/authorized_keys? People who follow this instruction would never know they were 0wned.

Hari KT (@harikt) wrote at 8/13/2014 10:46 pm:

I hate the require-dev to see phpunit, and all the stuffs when I can install it globally :/ .

Petah wrote at 8/13/2014 11:37 pm:

@voodooKobra Thats ridiculous. You can trust it as much as you can downloading any executable from a website running it.

Spudley wrote at 8/15/2014 10:15 am:

@Petah: You’re right; you can trust it as much as any executable you download. The point is that you *can’t* trust any executable you download. Most companies that have a securty policy will include a clause that bans staff from simply downloading arbitrary executables without having them approved first. Strike one, Composer.

The second problem is that third party updates can break your code. This has happened to me recently: A library I was using got a minor update. That update included a bug which caused my code to crash. I reported it to the author and he fixed it pretty quickly, but we came very close to releasing our software with a serious error because of a minor update to a third party library. And yes, I could have locked Composer down to a specific version, but that kinda defeats the whole point of using Composer. As it is, I had already locked it down to only getting minor releases, but that’s what I got, and that’s what broke.

The third problem is reliablility. If Composer can’t download your updates then everything breaks. Again, I’ve had this recently when our own corporate network suffered a bandwidth issue: Composer couldn’t get the bandwidth to download the updates it wanted; my build failed and I couldn’t deploy. In this case it was our own network that caused the problem, but we’re relying just as much on Packagist and Github to be working. That’s three separate points of failure, all of which are introduced by using Composer.

The bottom line is that Composer introduces a lot of potential problems, especially for corporate users.

It does also have a lot of benefits, and they’re powerful enough that I’ve managed to convince my security-conscious employer that we should use Composer despite the issues, but many others would not be able to do that.

There is a solution to all of this, in the shape of Toran Proxy (https://toranproxy.com/), which is a tool written by the author of Composer to directly address all of the above points. It does come at a cost, but it’s not extortionate. I’m currently evaluating it, so I can’t tell you whether it’s any good just yet, but if it does solve the issues I’ve described then it will be worth every penny. And at that point, using Composer will become a no-brainer, even for the most up-tight organisation.

Copyright © 2023 by Brandon Savage. All rights reserved.