You've already learned how to use the command-line interface to do some things. This chapter documents all the available commands.
To get help from the command-line, simply call composer or composer list to see the complete list of commands, then --help combined with any of those can give you more information.
As Composer uses symfony/console you can call commands by short name if it's not ambiguous.
composer dump
calls composer dump-autoload.
The following options are available with every command:
In the Libraries chapter we looked at how to create a composer.json by hand. There is also an init command available that makes it a bit easier to do this.
When you run the command it will interactively ask you to fill in the fields, while using some smart defaults.
php composer.phar init
foo/bar:1.0.0.minimum-stability field.composer repository or a JSON string which similar to what the repositories key accepts.The install command reads the composer.json file from the current directory, resolves the dependencies, and installs them into vendor.
php composer.phar install
If there is a composer.lock file in the current directory, it will use the exact versions from there instead of resolving them. This ensures that everyone using the library will get the same versions of the dependencies.
If there is no composer.lock file, Composer will create one after dependency resolution.
source and dist. For stable versions Composer will use the dist by default. The source is a version control repository. If --prefer-source is enabled, Composer will install from source if there is one. This is useful if you want to make a bugfix to a project and get a local git clone of the dependency directly.--prefer-source, Composer will install from dist if possible. This can speed up installs substantially on build servers and other use cases where you typically do not run updates of the vendors. It is also a way to circumvent problems with git if you do not have a proper setup.--dry-run. This will simulate the installation and show you what would happen.require-dev (this is the default behavior).require-dev. The autoloader generation skips the autoload-dev rules.composer.json.--optimize-autoloader.php, hhvm, lib-* and ext-* requirements and force the installation even if the local machine does not fulfill these. See also the platform config option.In order to get the latest versions of the dependencies and to update the composer.lock file, you should use the update command. This command is also aliased as upgrade as it does the same as upgrade does if you are thinking of apt-get or similar package managers.
php composer.phar update
This will resolve all dependencies of the project and write the exact versions into composer.lock.
If you only want to update a few packages and not all, you can list them as such:
php composer.phar update vendor/package vendor/package2
You can also use wildcards to update a bunch of packages at once:
php composer.phar update "vendor/*"
source when available.dist when available.require-dev (this is the default behavior).require-dev. The autoloader generation skips the autoload-dev rules.composer.json.--optimize-autoloader.php, hhvm, lib-* and ext-* requirements and force the installation even if the local machine does not fulfill these. See also the platform config option.--prefer-stable.The require command adds new packages to the composer.json file from the current directory. If no file exists one will be created on the fly.
php composer.phar require
After adding/changing the requirements, the modified requirements will be installed or updated.
If you do not want to choose requirements interactively, you can pass them to the command.
php composer.phar require vendor/package:2.* vendor/package2:dev-master
If you do not specify a package, composer will prompt you to search for a package, and given results, provide a list of matches to require.
require-dev.source when available.dist when available.composer.json.--no-dev option.php, hhvm, lib-* and ext-* requirements and force the installation even if the local machine does not fulfill these. See also the platform config option.--prefer-stable.composer.json.--optimize-autoloader.The remove command removes packages from the composer.json file from the current directory.
php composer.phar remove vendor/package vendor/package2
After removing the requirements, the modified requirements will be uninstalled.
require-dev.composer.json.php, hhvm, lib-* and ext-* requirements and force the installation even if the local machine does not fulfill these. See also the platform config option.--optimize-autoloader.The check-platform-reqs command checks that your PHP and extensions versions match the platform requirements of the installed packages. This can be used to verify that a production server has all the extensions needed to run a project after installing it for example.
Unlike update/install, this command will ignore config.platform settings and check the real platform packages so you can be certain you have the required platform dependencies.
The global command allows you to run other commands like install, remove, require or update as if you were running them from the COMPOSER_HOME directory.
This is merely a helper to manage a project stored in a central location that can hold CLI tools or Composer plugins that you want to have available everywhere.
This can be used to install CLI utilities globally. Here is an example:
php composer.phar global require friendsofphp/php-cs-fixer
Now the php-cs-fixer binary is available globally. Make sure your global vendor binaries directory is in your $PATH environment variable, you can get its location with the following command :
php composer.phar global config bin-dir --absolute
If you wish to update the binary later on you can run a global update:
php composer.phar global update
The search command allows you to search through the current project's package repositories. Usually this will be packagist. You simply pass it the terms you want to search for.
php composer.phar search monolog
You can also search for more than one term by passing multiple arguments.
To list all of the available packages, you can use the show command.
php composer.phar show
To filter the list you can pass a package mask using wildcards.
php composer.phar show monolog/* monolog/monolog 1.19.0 Sends your logs to files, sockets, inboxes, databases and various web services
If you want to see the details of a certain package, you can pass the package name.
php composer.phar show monolog/monolog name : monolog/monolog versions : master-dev, 1.0.2, 1.0.1, 1.0.0, 1.0.0-RC1 type : library names : monolog/monolog source : [git] https://github.com/Seldaek/monolog.git 3d4e60d0cbc4b888fe5ad223d77964428b1978da dist : [zip] https://github.com/Seldaek/monolog/zipball/3d4e60d0cbc4b888fe5ad223d77964428b1978da 3d4e60d0cbc4b888fe5ad223d77964428b1978da license : MIT autoload psr-0 Monolog : src/ requires php >=5.3.0
You can even pass the package version, which will tell you the details of that specific version.
php composer.phar show monolog/monolog 1.0.2
The outdated command shows a list of installed packages that have updates available, including their current and latest versions. This is basically an alias for composer show -lo.
The color coding is as such:
composer show -l).The browse (aliased to home) opens a package's repository URL or homepage in your browser.
Lists all packages suggested by currently installed set of packages. You can optionally pass one or multiple package names in the format of vendor/package to limit output to suggestions made by those packages only.
Use the --by-package or --by-suggestion flags to group the output by the package offering the suggestions or the suggested packages respectively.
Use the --verbose (-v) flag to display the suggesting package and the suggestion reason. This implies --by-package --by-suggestion, showing both lists.
require-dev packages.The depends command tells you which other packages depend on a certain package. As with installation require-dev relationships are only considered for the root package.
php composer.phar depends doctrine/lexer doctrine/annotations v1.2.7 requires doctrine/lexer (1.*) doctrine/common v2.6.1 requires doctrine/lexer (1.*)
You can optionally specify a version constraint after the package to limit the search.
Add the --tree or -t flag to show a recursive tree of why the package is depended upon, for example:
php composer.phar depends psr/log -t psr/log 1.0.0 Common interface for logging libraries |- aboutyou/app-sdk 2.6.11 (requires psr/log 1.0.*) | `- __root__ (requires aboutyou/app-sdk ^2.6) |- monolog/monolog 1.17.2 (requires psr/log ~1.0) | `- laravel/framework v5.2.16 (requires monolog/monolog ~1.11) | `- __root__ (requires laravel/framework ^5.2) `- symfony/symfony v3.0.2 (requires psr/log ~1.0) `- __root__ (requires symfony/symfony ^3.0)
The prohibits command tells you which packages are blocking a given package from being installed. Specify a version constraint to verify whether upgrades can be performed in your project, and if not why not. See the following example:
php composer.phar prohibits symfony/symfony 3.1 laravel/framework v5.2.16 requires symfony/var-dumper (2.8.*|3.0.*)
Note that you can also specify platform requirements, for example to check whether you can upgrade your server to PHP 8.0:
php composer.phar prohibits php:8 doctrine/cache v1.6.0 requires php (~5.5|~7.0) doctrine/common v2.6.1 requires php (~5.5|~7.0) doctrine/instantiator 1.0.5 requires php (>=5.3,<8.0-DEV)
As with depends you can request a recursive lookup, which will list all packages depending on the packages that cause the conflict.
You should always run the validate command before you commit your composer.json file, and before you tag a release. It will check if your composer.json is valid.
php composer.phar validate
composer.json use unbound or overly strict version constraints.composer.lock exists and is not up to date.composer.json is unsuitable for publishing as a package on Packagist but is otherwise valid.If you often need to modify the code of your dependencies and they are installed from source, the status command allows you to check if you have local changes in any of them.
php composer.phar status
With the --verbose option you get some more information about what was changed:
php composer.phar status -v
You have changes in the following dependencies:
vendor/seld/jsonlint:
M README.mdown To update Composer itself to the latest version, run the self-update command. It will replace your composer.phar with the latest version.
php composer.phar self-update
If you would like to instead update to a specific release simply specify it:
php composer.phar self-update 1.0.0-alpha7
If you have installed Composer for your entire system (see global installation), you may have to run the command with root privileges
sudo -H composer self-update
The config command allows you to edit composer config settings and repositories in either the local composer.json file or the global config.json file.
Additionally it lets you edit most properties in the local composer.json.
php composer.phar config --list
config [options] [setting-key] [setting-value1] ... [setting-valueN]
setting-key is a configuration option name and setting-value1 is a configuration value. For settings that can take an array of values (like github-protocols), more than one setting-value arguments are allowed.
You can also edit the values of the following properties:
description, homepage, keywords, license, minimum-stability, name, prefer-stable, type and version.
See the Config chapter for valid configuration options.
$COMPOSER_HOME/config.json by default. Without this option, this command affects the local composer.json file or a file specified by --file.EDITOR env variable. With the --global option, this opens the global config file.setting-key.--global option this lists the global configuration only.--global option.In addition to modifying the config section, the config command also supports making changes to the repositories section by using it the following way:
php composer.phar config repositories.foo vcs https://github.com/foo/bar
If your repository requires more configuration options, you can instead pass its JSON representation :
php composer.phar config repositories.foo '{"type": "vcs", "url": "http://svn.example.org/my-project/", "trunk-path": "master"}' In addition to modifying the config section, the config command also supports making changes to the extra section by using it the following way:
php composer.phar config extra.foo.bar value
The dots indicate array nesting, a max depth of 3 levels is allowed though. The above would set "extra": { "foo": { "bar": "value" } }.
You can use Composer to create new projects from an existing package. This is the equivalent of doing a git clone/svn checkout followed by a composer install of the vendors.
There are several applications for this:
To create a new project using Composer you can use the create-project command. Pass it a package name, and the directory to create the project in. You can also provide a version as third argument, otherwise the latest version is used.
If the directory does not currently exist, it will be created during installation.
php composer.phar create-project doctrine/orm path 2.2.*
It is also possible to run the command without params in a directory with an existing composer.json file to bootstrap a project.
By default the command checks for the packages on packagist.org.
stable.source when available.dist when available.composer repository, a path to a local packages.json file, or a JSON string which similar to what the repositories key accepts.require-dev.php, hhvm, lib-* and ext-* requirements and force the installation even if the local machine does not fulfill these.If you need to update the autoloader because of new classes in a classmap package for example, you can use dump-autoload to do that without having to go through an install or update.
Additionally, it can dump an optimized autoloader that converts PSR-0/4 packages into classmap ones for performance reasons. In large applications with many classes, the autoloader can take up a substantial portion of every request's time. Using classmaps for everything is less convenient in development, but using this option you can still use PSR-0/4 for convenience and classmaps for performance.
composer.json file.--optimize.Deletes all content from Composer's cache directories.
Lists the name, version and license of every package installed. Use --format=json to get machine readable output.
To run scripts manually you can use this command, give it the script name and optionally any required arguments.
Executes a vendored binary/script. You can execute any command and this will ensure that the Composer bin-dir is pushed on your PATH before the command runs.
If you think you found a bug, or something is behaving strangely, you might want to run the diagnose command to perform automated checks for many common problems.
php composer.phar diagnose
This command is used to generate a zip/tar archive for a given package in a given version. It can also be used to archive your entire project without excluded/ignored files.
php composer.phar archive vendor/package 2.0.21 --format=zip
To get more information about a certain command, you can use help.
php composer.phar help install
Command-line completion can be enabled by following instructions on this page.
You can set a number of environment variables that override certain settings. Whenever possible it is recommended to specify these settings in the config section of composer.json instead. It is worth noting that the env vars will always take precedence over the values specified in composer.json.
By setting the COMPOSER env variable it is possible to set the filename of composer.json to something else.
For example:
COMPOSER=composer-other.json php composer.phar install
The generated lock file will use the same name: composer-other.lock in this example.
If set to 1, this env disables the warning about running commands as root/super user. It also disables automatic clearing of sudo sessions, so you should really only set this if you use Composer as super user at all times like in docker containers.
The COMPOSER_AUTH var allows you to set up authentication as an environment variable. The contents of the variable should be a JSON formatted object containing http-basic, github-oauth, bitbucket-oauth, ... objects as needed, and following the spec from the config.
By setting this option you can change the bin (Vendor Binaries) directory to something other than vendor/bin.
The COMPOSER_CACHE_DIR var allows you to change the Composer cache directory, which is also configurable via the cache-dir option.
By default it points to $COMPOSER_HOME/cache on *nix and macOS, and C:\Users\<user>\AppData\Local\Composer (or %LOCALAPPDATA%/Composer) on Windows.
By setting this environmental value, you can set a path to a certificate bundle file to be used during SSL/TLS peer verification.
This env var controls the discard-changes config option.
The COMPOSER_HOME var allows you to change the Composer home directory. This is a hidden, global (per-user on the machine) directory that is shared between all projects.
By default it points to C:\Users\<user>\AppData\Roaming\Composer on Windows and /Users/<user>/.composer on macOS. On *nix systems that follow the XDG Base Directory Specifications, it points to $XDG_CONFIG_HOME/composer. On other *nix systems, it points to /home/<user>/.composer.
You may put a config.json file into the location which COMPOSER_HOME points to. Composer will merge this configuration with your project's composer.json when you run the install and update commands.
This file allows you to set repositories and configuration for the user's projects.
In case global configuration matches local configuration, the local configuration in the project's composer.json always wins.
Defaults to 1. If set to 0, Composer will not create .htaccess files in the composer home, cache, and data directories.
If set, the value is used as php's memory_limit.
If set to 1, this env changes the default path repository strategy to mirror instead of symlink. As it is the default strategy being set it can still be overwritten by repository options.
If set to 1, this env var will make Composer behave as if you passed the --no-interaction flag to every command. This can be set on build boxes/CI.
This env var controls the time Composer waits for commands (such as git commands) to finish executing. The default value is 300 seconds (5 minutes).
By setting this var you can specify the version of the root package, if it can not be guessed from VCS info and is not present in composer.json.
By setting this var you can make Composer install the dependencies into a directory other than vendor.
If you are using Composer from behind an HTTP proxy, you can use the standard http_proxy or HTTP_PROXY env vars. Simply set it to the URL of your proxy. Many operating systems already set this variable for you.
Using http_proxy (lowercased) or even defining both might be preferable since some tools like git or curl will only use the lower-cased http_proxy version. Alternatively you can also define the git proxy using git config --global http.proxy <proxy url>.
If you are using Composer in a non-CLI context (i.e. integration into a CMS or similar use case), and need to support proxies, please provide the CGI_HTTP_PROXY environment variable instead. See httpoxy.org for further details.
If you use a proxy but it does not support the request_fulluri flag, then you should set this env var to false or 0 to prevent Composer from setting the request_fulluri option.
If you use a proxy but it does not support the request_fulluri flag for HTTPS requests, then you should set this env var to false or 0 to prevent Composer from setting the request_fulluri option.
If set, makes the self-update command write the new Composer phar file into that path instead of overwriting itself. Useful for updating Composer on read-only filesystem.
If you are behind a proxy and would like to disable it for certain domains, you can use the no_proxy or NO_PROXY env var. Simply set it to a comma separated list of domains the proxy should not be used for.
The env var accepts domains, IP addresses, and IP address blocks in CIDR notation. You can restrict the filter to a particular port (e.g. :80). You can also set it to * to ignore the proxy for all HTTP requests.
© Nils Adermann, Jordi Boggiano
Licensed under the MIT License.
https://getcomposer.org/doc/03-cli.md