Locally

To install Composer locally , simply run the following command in your project directory:

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

Once the installer runs, it will download the composer.phar binary to your project. You can then execute it by running php composer.phar.

Globally

To install Composer as a system-wide executable, you will first download the composer.phar then move it to somewhere that is within your PATH on Unix-like systems (Linux/OS X, etc.):

$ curl -sS https://getcomposer.org/installer | php
$ sudo mv composer.phar /usr/local/bin/composer

You can now execute Composer by typing composer on the command line.

The composer.json File

In the most basic form, the only thing that is required is the use of the require key. For our example, we’ll install the PHPUnit framework. We’ll create the project’s composer.json file like this:

{
  "require": {
    "phpunit/phpunit": "4.8.4"
  }
}

Now we’ll install this framework with Composer, like this:

$ composer install

After running this command, we will see output from Composer as it downloads and installs all of the dependencies needed for PHPUnit, which will look something like this:

$ composer install
Loading composer repositories with package information
Installing dependencies (including require-dev)
  - Installing sebastian/version (1.0.6)
    Loading from cache

  - Installing sebastian/global-state (1.0.0)
    Loading from cache

  - Installing sebastian/recursion-context (1.0.1)
    Downloading: 100%         

As Composer finishes its installation, you will see it generates a lock file and the autoload files needed to automatically load PHPUnit into your application. You will also have a new folder called vendor that includes all of the packages that Composer just installed.

Installing Additional Packages

Now, when you need to install additional packages into your application, you simply add the entry or entries for your new requirements to your composer.json file and run composer install again. Alternatively, you can make use of the composer require command, which will both add the entry to your composer.json file and install it in one command. For example, one of our application requirements might be to send emails, and we want to use the popular SwiftMailer library. To do this, we first look up SwiftMailer on packagist.com and find the package name, then we run the following command:

$ composer require swiftmailer/swiftmailer
Using version ^5.4 for swiftmailer/swiftmailer
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing swiftmailer/swiftmailer (v5.4.1)
    Downloading: 100%         

Writing lock file
Generating autoload files

From the output, we can see it updated our composer.json file, installed the SwiftMailer library package, updated the lock file, and generated new autoload files. If you look at the composer.json file, you’ll now see it updated to reflect SwiftMailer:

{                                                                                                    
  "require": {
    "phpunit/phpunit": "4.8.4",
    "swiftmailer/swiftmailer": "^5.4"
  }
}

One thing you might notice with the new entry in the composer.json file is the version number for SwiftMailer—it includes the caret (^) operator. We’ll dive deeper into Composer versions in a few sections, but for now this is the equivalent of telling future composer update commands that we always want the latest stable release that is >=5.4 < 6.0. If we wanted to be more specific with a version, like in the PHPUnit example, then we can optionally pass along a version to the composer require command, like so:

$ composer require swiftmailer/swiftmailer 5.4

Removing Packages

Composer makes adding new libraries to your application easy, and it makes it just as easy to remove packages that are no longer needed. There are two different ways this can be accomplished—either by manually removing the package declaration from your composer.json file and running composer update or by utilizing the composer remove command .

If we decide we want to remove the PHPUnit library we installed previously, we can do so with this single command:

$ composer remove phpunit/phpunit
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Removing phpunit/phpunit (4.8.4)
Writing lock file
Generating autoload files

require vs require-dev

Composer makes available two different methods of requiring a package. The first is by using the require declaration, as all of the previous examples have shown. The second is by using the require-dev declaration. You should always use require unless a certain package is only needed for the development of your application and not for running the application in production. A prime example for this would be a unit-testing library, such as PHPUnit. For example, let’s now add PHPUnit back into our application, but this time specify that it’s only needed for development using require-dev:

$ composer require phpunit/phpunit --dev
Using version ^4.8 for phpunit/phpunit
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing phpunit/phpunit (4.8.8)
    Downloading: 100%         

phpunit/phpunit suggests installing phpunit/php-invoker (∼1.1)
Writing lock file
Generating autoload files

Now if you look at the composer.json file, you will see phpunit has been added back, but this time under the require-dev declaration:

{
  "require": {
    "swiftmailer/swiftmailer": "^5.4"
  },
  "require-dev": {
    "phpunit/phpunit": "^4.8"
  }
}

The Composer Lock File

The Composer lock file is a list of the exact versions that Composer has installed into your project. This locks your project into those specific versions. It is important to add this lock file to your Git repository along with the composer.json file so that anyone working on your project will be using the same package versions. This is also important because if you’re using any type of deployment scheme in your staging or production environments, you can utilize composer install to ensure those environments have installed the same exact versions of your packages that you have developed your application against. This also ensures that future updates to these libraries can be done within your application development, committed to your repository, and accurately distributed to these other environments. This also eliminates the need to store all of the various packages that Composer has installed in your source code repository .

Autoloading

When using Composer, it will generate an autoload file vendor/autoload.php that is used to autoload all of your libraries and packages you have installed with Composer. Simply include this autoload file in your application (ensuring the correct path to the vendor/autoload.php file), and all of the installed packages will be available to you.

require __DIR__ . '/../vendor/autoload.php';

Now, if we wanted to use our SwiftMailer library we installed previously, we could do so simply by calling it:

// Create the SwiftMailer Transport
$transport = Swift_MailTransport::newInstance();

// Create a Mailer instance with our Transport
$mailer = Swift_Mailer::newInstance($transport);

// Create our message
$message = Swift_Message::newInstance('Learning Composer')
    ->setFrom(array('[email protected]' => 'John Doe'))
    ->setTo(array('[email protected]' => 'Jane Doe'))
    ->setBody('Composer is wonderful!');

// Send our message!
$result = $mailer->send($message);                                                                                                               

Additional Autoloading

In addition to autoloading all of the installed Composer library packages, you can utilize the Composer autoloader for your own application code as well. To do so, use the “autoload” field in your composer.json file.

For example, if you’re storing your own application’s code in a folder called src, you would add the following entry to your composer.json file :

{
  "autoload": {
    "psr-4": { "MyApplication\": "src/" }
  },
  "require": {
    "swiftmailer/swiftmailer": "^5.4"
  }
}

This tells Composer to register a PSR-4 (The PHP-FIG Autoloading Standard) autoloader for the “MyApplication” namespace. Now, to get Composer to update vendor/autoload.php, you will need to run the dump-autoload command:

$ composer dump-autoload
Generating autoload files

In addition to PSR-4 autoloading, Composer also supports the PSR-0 autoloading, classmap generation, and file includes as valid autoloading methods. However, PSR-4 is the recommended method of autoloading with Composer for its ease of use.

Autoloader Optimization

Although not required for development environments, it is highly recommended that when generating the Composer autoloader for production use, you utilize the built-in autoloader optimizer. It is not uncommon to see performance boosts in your application up to 30 percent, especially if your application is spending a lot of time on the Composer autoload file.

There are two different ways to generate an optimized autoloader. The first is by using the dump-autoload command with the -o parameter:

$ composer dump-autoload -o
Generating optimized autoload files

For example, this command could be set up to run on staging and production environment deployments so that the standard autoloader is being used in development, but testing and production use are utilizing the optimized version.

In addition to generating the optimized autoloader via the dump-autoload command, you can also specify it in your composer.json file so that you are always generating the optimized version. This is done using the config directive:

{
  "autoload": {
    "psr-4": {
      "MyApplication\": "src/"
    }
  },
  "require": {
    "swiftmailer/swiftmailer": "^5.4"
  },
  "require-dev": {
    "phpunit/phpunit": "^4.8"
  },
  "config": {
    "optimize-autoloader": true
  }
}

Package Versions

Composer provides a lot of flexibility when defining the version of a given package that you’re installing in your application. You can essentially break down the definitions into three categories: basic constraints, next signification release, and stability .

Basic Constraints

"require": {
    "vendor/packagea": "1.5.4"
  }

"require": {
    "vendor/packagea": ">1.5",
    "vendor/packageb": ">2.0 <3.0",
    "vendor/packagec": ">2.0,<3.0",
    "vendor/packaged": ">1.0 <1.5 || >= 1.7"
}

"require": {
    "vendor/packagea": "4.2.*"
}

"require": {
    "vendor/packagea": "1.5 – 2.0",
    "vendor/packageb": "2.0 – 2.1.0"
  }

Next Significant Release

There are two different operators you can use with Composer to define a version limit up to the next significant release of a given package.

"require": {
    "vendor/packagea": "∼2.5"
}

"require": {
    "vendor/packagea": "∼2.5.2"
}

"require": {
    "vendor/packagea": "^2.5.2"
}

"require": {
    "vendor/packagea": "∼0.5"
}

Stability

The Composer documentation can become quite confusing when trying to understand the stability of a package that Composer will install. Reading the “Versions” section of the Composer documentation would lead you to think that Composer might randomly pick a dev version of a package solely based on the constraint that you use when specifying the version.

Although this is technically true, this will only apply if you have specified the minimum stability to be dev in your composer.json file. By default, Composer will always select stable packages unless you specifically tell it otherwise using the -dev suffix under the require section, or if you have defined the minimum-stability configuration to dev.

Updating Packages

So far we’ve covered how to install and remove packages with Composer, as well as how to specify the version and stability of the packages your application relies on. The last major operation you will be doing with Composer will be to update your existing libraries. This is performed using the composer update command :

$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Generating autoload files

By default, when running composer update, a number of actions are performed. First, if you have made any manual changes to your composer.json file to add or remove a package, it will process those and will install or remove the given packages. Additionally, if any of your package versions are not locked to an exact version, it will look for any updates and install them according to your version specification. Lastly, it will regenerate the autoloading file and lock file and finish its operations.

There are a number of options you can pass to composer update. For example, by passing --dry-run you can see what Composer would do before actually doing it. You may choose to pass --no-dev, which will cause it to skip updating or installing any packages defined under the require-dev declaration. You can also define specific packages that you want it to update without updating all of the packages defined in your composer.json file. You do this by passing one or many packages to it, such as:

$ composer update swiftmailer/swiftmailer guzzlehttp/guzzle

Installing Packages Globally

Composer can be used to manage and install packages globally , similar to PEAR. This can be useful for installing certain utilities globally or even for maintaining updates to a global install of Composer itself.

As an example, if we wanted to update our global version of Composer, we would run the following command:

$ sudo composer self-update

If we wanted to install a utility such as PHPUnit, we would use a command like this one:

$ composer global require phpunit/phpunit
Changed current directory to /home/vagrant/.config/composer
You are running composer with xdebug enabled. This has a major impact on runtime performance. See https://getcomposer.org/xdebug
Using version ^5.2 for phpunit/phpunit
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
...
Writing lock file
Generating autoload files

Pay attention to the line that immediately follows when executing this command: Changed current directory to. This tells you it will install PHPUnit and its dependencies under /home/vagrant/.config/composer/vendor/. Our current user we’re logged in as is “vagrant.” which is why it chose this directory. You will need to add this directory to your global path for easy execution. Adjust the following command accordingly if you have a .bashrc or a .bash_profile file in your home directory. In my case, I have a .bashrc file, so that is what I’ll use:

$ cd ∼/
$ echo 'export PATH="$PATH:$HOME/.config/composer/vendor/bin"' >> ∼/.bashrc

Now, reload to pick up the path changes, either by logging out and back in or by using the source command:

$ source .bashrc

You can now execute phpunit:

$ phpunit --version
PHPUnit 5.2.9 by Sebastian Bergmann and contributors.

Installing a Global Utility Using PEAR

$ sudo pear install PHP_CodeSniffer
downloading PHP_CodeSniffer-2.5.1.tgz ...
Starting to download PHP_CodeSniffer-2.5.1.tgz (484,780 bytes)
....................done: 484,780 bytes
install ok: channel://pear.php.net/PHP_CodeSniffer-2.5.1

PHP CodeSniffer is now immediately available for your use. You can test if it is working like this:

$ phpcs --version
PHP_CodeSniffer version 2.5.1 (stable) by Squiz (http://www.squiz.net)

If you receive a warning when trying to run the previous command, such as PHP Warning:  include_once(PHP/CodeSniffer/CLI.php): failed to open stream: No such file or directory, this means that your php.ini for the PHP CLI either does not exist or does not have the PEAR install path added to the php path. You can check this by following these steps, first checking the include path of pear installed on your system:

$ pear config-get php_dir
/usr/lib/php/pear

Now check which configuration file your PHP CLI is using:

$ php --ini
Configuration File (php.ini) Path: /etc/php/7.0/cli
Loaded Configuration File:         /etc/php/7.0/cli/php.ini

This will give more output than the preceding code, but you want to look for the Loaded Configuration File line.

Now, taking the path of the configuration file listed previously, check the PHP include path:

$ php -c /etc/php/7.0/cli/php.ini -r 'echo get_include_path()."
";'
.:/usr/share/php:

So, as you can see, the include path does not include the pear include path. To solve this, we’ll open php.ini and add it to the include_path directive like this:

include_path = ".:/usr/share/php:/usr/lib/php/pear"

If you try to execute the phpcs command again, it will now execute because it knows where to include the files from.