PHP

Composer Cheatsheet

Matthew Setter
Share

This article was sponsored by AppDynamics. Thank you for supporting the sponsors who make SitePoint possible!

Unless you’ve been living under a rock, today’s PHP isn’t your grandmother’s PHP; it’s an entirely different, much more elegant and mature language with countless improvements and additions.

One of the key additions is Composer, the de facto standard for managing PHP project dependencies which, by default, gives you access to hundreds of ready-made libraries, via Packagist.org.

I’m not going to go over how to use Composer, as it’s been covered so well here on SitePoint already; especially by this article, by Alexander Cogneau.

Instead, I’m approaching it from a different angle, taking you through the excellent Composer cheat sheet, which I came across recently.

If you’d rather watch a quick video overview, play the embedded one below. Otherwise, continue reading. I encourage you to do both.

Like any complex, feature rich, tool there’s so much that you can do with Composer. For example, you can use the composer.phar file to:

  • Add composer support to an existing project
  • Run scripts in response to various events, such as pre and post install, pre and post package updates
  • Specify custom autoloaders
  • Differentiate dependencies, based on whether the project is in development, testing, live, or another specific environment
  • Make use of the hundreds of readily available packages via Packagist.org

Through these samples alone, you can see that there’s a lot of functionality, as well as a lot to remember.

So whilst you use it in every project, do you know all that it has to offer? Or do you use the same set of command line switches and configuration options time and time again, without thinking about what else is available?

I’d suggest, if you’re anything like me, you’re in the latter camp. Today I want to help you rectify that and really get the most out of Composer, by going through the cheat sheet.

I’m sure you’ll see just why it’s so well deserving of the name; and before long you’ll start having it in a pinned tab, much like the PHP manual. It’s that good!

2 Key Parts

Essentially, it’s comprised of two key parts:

  1. The composer.phar command line switches
  2. The composer.json file

The composer.phar Command Line Switches

This section lists all of the command line switches you can pass to composer.phar, at the command line. What’s more, by mousing over them, on the right hand side, you’ll see a fuller description of what each one does.

It lists everything from the most common, regularly, used options to the more advanced. Here’s a sample:

  • install – which sets up the dependencies in the vendor directory
  • self-update – which updates the composer.phar file to the latest version
  • init – which sets up composer support in an existing, or new, project
  • validate – which valises an existing composer.json file
  • diagnose – for performing automated checks
  • archive – which creates an archive of the composer package.

By using the cheat sheet, I learned that by passing the --optimize switch to dump-autoload, you can get anything up to a 20% performance boost in your projects.

None too shabby, wouldn’t you say? Ok, I could have found this out through testing, or dug through the documentation, but the cheat sheet made it quick and easy to find.

The composer.json File Configuration

I’d suggest this is the section where you’ll spend most of your time with the cheat sheet. Whilst calling composer.phar can largely be scripted away, the per/project configurations you need may differ regularly enough to require a variety of different options each time.

So the composer.json section is definitely your friend in this regard. As with composer.phar, it displays an example, utilising every option. It lists all the options right from the most common, such as name, description, authors, and require which provide key information about the package, along with its dependencies.

Authors is a good example, showing the name, email, homepage, and role of 2 sample authors, which you can see below:

"authors": [
    {
        "name": "Xavier Lacot",
        "email": "xlacot@jolicode.com",
        "homepage": "http://www.lacot.org",
        "role": "Developer"
    },
    {
        "name": "Benjamin Clay",
        "email": "bclay@jolicode.com",
        "homepage": "http://ternel.net",
        "role": "Developer"
    }
],

Then there’s the more advanced ones which we likely use not as often.

  • support – where you find the list of support options, for when users need assistance
  • autoload – where you can set specific autoload mapping options for the PHP autoloader
  • repositories – allowing you to go beyond the standard Packagist backend, adding PEAR, use version control tools, such as GitHub, Bitbucket or a self-hosted, private, packages using Satis.

Here’s a sample of the scripts section. You can see that it lists how to use static class methods, of namespaced classes, to respond to several events.

"scripts": {
    "post-update-cmd": MyVendor\\MyClass::postUpdate",
    "post-package-install": [
        "MyVendor\\MyClass::postPackageInstall"
    ],
    "post-install-cmd": [
        "MyVendor\\MyClass::warmCache",
        "phpunit -c app/"
    ]
},

As with the composer.phar section, by mousing over them, you’ll see the section specifics, on the right hand side, as well as example uses.

 Conclusion

I believe it’s a great tool for getting the most out of Composer. Some might say that at one page long, it’s not sufficiently detailed; I disagree.

The way the cheat sheet is composed, showing sample usages of each command line option, and listing out a complete composer.json file example, combined with a detailed description and further usage examples of each aspect, is an elegant approach.

You’re able to get as much information as you need, without being overloaded. What do you think? Do you think it could go further, and provide more information? Or is it just the right length? Share your thoughts in the comments.

As it’s Open Source, if you see something that needs improving, a typo, or generally want to add more information, get in there, fork it and send a Pull Request.

Otherwise, enjoy.