Composer 是 PHP 的一个依赖管理工具。它允许你申明项目所依赖的代码库，它会在你的项目中为你安装他们。
Composer 不是一个包管理器。是的，它涉及 "packages" 和 "libraries"，但它在每个项目的基础上进行管理，在你项目的某个目录中（例如 vendor）进行安装。默认情况下它不会在全局安装任何东西。因此，这仅仅是一个依赖管理。
这种想法并不新鲜，Composer 受到了 node's [npm][1] 和 ruby's [bundler][2] 的强烈启发。而当时 PHP 下并没有类似的工具。
Composer 将这样为你解决问题：
a) 你有一个项目依赖于若干个库。
b) 其中一些库依赖于其他库。
c) 你声明你所依赖的东西。
d) Composer 会找出哪个版本的包需要安装，并安装它们（将它们下载到你的项目中）。
比方说，你正在创建一个项目，你需要一个库来做日志记录。你决定使用 [monolog][3]。为了将它添加到你的项目中，你所需要做的就是创建一个 composer.json 文件，其中描述了项目的依赖关系。
{ "require": { "monolog/monolog": "1.2.*" }}我们只要指出我们的项目需要一些 monolog/monolog 的包，从 1.2 开始的任何版本。
运行 Composer 需要 PHP 5.3.2+ 以上版本。一些敏感的 PHP 设置和编译标志也是必须的，但对于任何不兼容项安装程序都会抛出警告。
我们将从包的来源直接安装，而不是简单的下载 zip 文件，你需要 git 、 svn 或者 hg ，这取决于你载入的包所使用的版本管理系统。
Composer 是多平台的，我们努力使它在 Windows 、 Linux 以及 OSX 平台上运行的同样出色。
要真正获取 Composer，我们需要做两件事。首先安装 Composer （同样的，这意味着它将下载到你的项目中）：
curl -sS https://getcomposer.org/installer | php注意： 如果上述方法由于某些原因失败了，你还可以通过 php >下载安装器：
php -r "readfile('https://getcomposer.org/installer');" | php这将检查一些 PHP 的设置，然后下载 composer.phar 到你的工作目录中。这是 Composer 的二进制文件。这是一个 PHAR 包（PHP 的归档），这是 PHP 的归档格式可以帮助用户在命令行中执行一些操作。
你可以通过 --install-dir 选项指定 Composer 的安装目录（它可以是一个绝对或相对路径）：
curl -sS https://getcomposer.org/installer | php -- --install-dir=bin你可以将此文件放在任何地方。如果你把它放在系统的 PATH 目录中，你就能在全局访问它。 在类Unix系统中，你甚至可以在使用时不加 php 前缀。
你可以执行这些命令让 composer 在你的系统中进行全局调用：
curl -sS https://getcomposer.org/installer | phpmv composer.phar /usr/local/bin/composer注意： 如果上诉命令因为权限执行失败， 请使用 sudo 再次尝试运行
mv那行命令。
现在只需要运行 composer 命令就可以使用 Composer 而不需要输入 php composer.phar。
Composer 是 homebrew-php 项目的一部分。
brew updatebrew tap josegonzalez/homebrew-phpbrew tap homebrew/versionsbrew install php55-intlbrew install josegonzalez/php/composer这是将 Composer 安装在你机器上的最简单的方法。
下载并且运行 [Composer-Setup.exe][4]，它将安装最新版本的 Composer ，并设置好系统的环境变量，因此你可以在任何目录下直接使用 composer 命令。
设置系统的环境变量 PATH 并运行安装命令下载 composer.phar 文件：
C:Usersusername>cd C:binC:bin>php -r "readfile('https://getcomposer.org/installer');" | php注意： 如果收到 readfile 错误提示，请使用 http 链接或者在 php.ini 中开启 php_openssl.dll 。
在 composer.phar 同级目录下新建文件 composer.bat ：
C:bin>echo @php "%~dp0composer.phar" %*>composer.bat关闭当前的命令行窗口，打开新的命令行窗口进行测试：
C:Usersusername>composer -VComposer version 27d8904现在我们将使用 Composer 来安装项目的依赖。如果在当前目录下没有一个 composer.json 文件，请查看[基本用法][5]章节。
要解决和下载依赖，请执行 install 命令：
php composer.phar install如果你进行了全局安装，并且没有 phar 文件在当前目录，请使用下面的命令代替：
composer install继续 上面的例子，这里将下载 monolog 到 vendor/monolog/monolog 目录。
除了库的下载，Composer 还准备了一个自动加载文件，它可以加载 Composer 下载的库中所有的类文件。使用它，你只需要将下面这行代码添加到你项目的引导文件中：
require 'vendor/autoload.php';现在我们就可以使用 monolog 了！想要学习更多关于 Composer 的知识，请查看"基本用法"章节。
本章将告诉你如何通过 Composer 来安装你的库。
只要你有一个 composer.json 文件在目录中，那么整个目录就是一个包。当你添加一个 require 到项目中，你就是在创建一个依赖于其它库的包。你的项目和库之间唯一的区别是，你的项目是一个没有名字的包。
为了使它成为一个可安装的包，你需要给它一个名称。你可以通过 composer.json 中的 name 来定义：
{ "name": "acme/hello-world", "require": { "monolog/monolog": "1.0.*" }}在这种情况下项目的名称为 acme/hello-world，其中 acme 是供应商的名称。供应商的名称是必须填写的。
注意： 如果你不知道拿什么作为供应商的名称， 那么使用你 github 上的用户名通常是不错的选择。 虽然包名不区分大小写，但惯例是使用小写字母，并用连字符作为单词的分隔。
Composer 将那些已经安装在系统上，但并不是由 Composer 安装的包视为一个虚拟的平台软件包。这包括PHP本身，PHP扩展和一些系统库。
php 表示用户的 PHP 版本要求，你可以对其做出限制。例如 >=5.4.0。如果需要64位版本的 PHP，你可以使用 php-64bit 进行限制。
hhvm 代表的是 HHVM（也就是 HipHop Virtual Machine） 运行环境的版本，并且允许你设置一个版本限制，例如，'>=2.3.3'。
ext-<name> 可以帮你指定需要的 PHP 扩展（包括核心扩展）。通常 PHP 拓展的版本可以是不一致的，将它们的版本约束为 * 是一个不错的主意。一个 PHP 扩展包的例子：包名可以写成 ext-gd。
lib-<name> 允许对 PHP 库的版本进行限制。curl、iconv、icu、libxml、openssl、pcre、uuid、xsl。你可以使用 composer show --platform 命令来获取可用的平台软件包的列表。
你需要一些方法来指明自己开发的包的版本，当你在 Packagist 上发布自己的包，它能够从 VCS (git, svn, hg) 的信息推断出包的版本，因此你不必手动指明版本号，并且也不建议这样做。请查看 标签 和 分支 来了解版本号是如何被提取的。
如果你想要手动创建并且真的要明确指定它，你只需要添加一个 version 字段：
{ "version": "1.0.0"}注意： 你应该尽量避免手动设置版本号，因为标签的值必须与标签名相匹配。
对于每一个看起来像版本号的标签，都会相应的创建一个包的版本。它应该符合 'X.Y.Z' 或者 'vX.Y.Z' 的形式，-patch、-alpha、-beta 或 -RC 这些后缀是可选的。在后缀之后也可以再跟上一个数字。
下面是有效的标签名称的几个例子：
v2.0.4-p1
注意： 即使你的标签带有前缀 v， 由于在需要 require 一个版本的约束时是不允许这种前缀的， 因此 v 将被省略（例如标签 V1.0.0 将创建 1.0.0 版本）。
对于每一个分支，都会相应的创建一个包的开发版本。如果分支名看起来像一个版本号，那么将创建一个如同 {分支名}-dev 的包版本号。例如一个分支 2.0 将产生一个 2.0.x-dev 包版本（加入了 .x 是出于技术的原因，以确保它被识别为一个分支，而 2.0.x 的分支名称也是允许的，它同样会被转换为 2.0.x-dev）。如果分支名看起来不像一个版本号，它将会创建 dev-{分支名} 形式的版本号。例如 master 将产生一个 dev-master 的版本号。
下面是版本分支名称的一些示例：
1.1.x
注意： 当你安装一个新的版本时，将会自动从它 source 中拉取。 详细请查看 install 命令。
它表示一个包版本的别名。例如，你可以为 dev-master 设置别名 1.0.x-dev，这样就可以通过 require 1.0.x-dev 来得到 dev-master 版本的包。
详细请查看别名。
如果你愿意，可以在你的项目中提交 composer.lock 文件。他将帮助你的团队始终针对同一个依赖版本进行测试。任何时候，这个锁文件都只对于你的项目产生影响。
如果你不想提交锁文件，并且你正在使用 Git，那么请将它添加到 .gitignore 文件中。
一旦你有一个包含 composer.json 文件的库存储在线上版本控制系统（例如：Git），你的库就可以被 Composer 所安装。在这个例子中，我们将 acme/hello-world 库发布在 GitHub 上的 github.com/username/hello-world 中。
现在测试这个 acme/hello-world 包，我们在本地创建一个新的项目。我们将它命名为 acme/blog。此博客将依赖 acme/hello-world，而后者又依赖 monolog/monolog。我们可以在某处创建一个新的 blog 文件夹来完成它，并且需要包含 composer.json 文件：
{ "name": "acme/blog", "require": { "acme/hello-world": "dev-master" }}在这个例子中 name 不是必须的，因为我们并不想将它发布为一个库。在这里为 composer.json 文件添加描述。
现在我们需要告诉我们的应用，在哪里可以找到 hello-world 的依赖。为此我们需要在 composer.json 中添加 repositories 来源申明：
{ "name": "acme/blog", "repositories": [ { "type": "vcs", "url": "https://github.com/username/hello-world" } ], "require": { "acme/hello-world": "dev-master" }}更多关于包的来源是如何工作的，以及还有什么其他的类型可供选择，请查看资源库。
这就是全部了。你现在可以使用 Composer 的 install 命令来安装你的依赖包了！
小结： 任何含有 composer.json 的 GIT、SVN、HG 存储库，都可以通过 require 字段指定“包来源”和“声明依赖”来添加到你的项目中。
好的，你现在可以发布你的包了，但你不会希望你的用户每次都这样繁琐的指定包的来源。
你可能注意到了另一件事，我们并没有指定 monolog/monolog 的来源。它是怎么工作的？答案是 packagist。
Packagist 是 Composer 主要的一个包信息存储库，它默认是启用的。任何在 packagist 上发布的包都可以直接被 Composer 使用。就像 monolog 它被 发布在 packagist 上，我们可以直接使用它，而不必指定任何额外的来源信息。
如果我们想与世界分享我们的 hello-world，我们最好将它发布到 packagist 上。这样做是很容易的。
你只需要点击那个大大的 "Submit Package" 按钮并注册。接着提交你库的来源地址，此时 packagist 就开始了抓取。一旦完成，你的包将可以提供给任何人使用。
你已经学会了如何使用命令行界面做一些事情。本章将向你介绍所有可用的命令。
为了从命令行获得帮助信息，请运行 composer 或者 composer list 命令，然后结合 --help 命令来获得更多的帮助信息。
下列参数可与每一个命令结合使用：
在 库 那一章我们看到了如何手动创建 composer.json 文件。实际上还有一个 init 命令可以更容易的做到这一点。
当您运行该命令，它会以交互方式要求您填写一些信息，同时聪明的使用一些默认值。
php composer.phar initfoo/bar:1.0.0 这样的格式。minimum-stability 字段的值。install 命令从当前目录读取 composer.json 文件，处理了依赖关系，并把其安装到 vendor 目录下。
php composer.phar install如果当前目录下存在 composer.lock 文件，它会从此文件读取依赖版本，而不是根据 composer.json 文件去获取依赖。这确保了该库的每个使用者都能得到相同的依赖版本。
如果没有 composer.lock 文件，composer 将在处理完依赖关系后创建它。
source 和 dist。对于稳定版本 composer 将默认使用 dist 方式。而 source 表示版本控制源 。如果 --prefer-source 是被启用的，composer 将从 source 安装（如果有的话）。如果想要使用一个 bugfix 到你的项目，这是非常有用的。并且可以直接从本地的版本库直接获取依赖关系。--prefer-source 相反，composer 将尽可能的从 dist 获取，这将大幅度的加快在 build servers 上的安装。这也是一个回避 git 问题的途径，如果你不清楚如何正确的设置。--dry-run 命令，它将模拟安装并显示将会发生什么。require-dev 字段中列出的包（这是一个默认值）。require-dev 字段中列出的包。composer.json 文件中定义的脚本。为了获取依赖的最新版本，并且升级 composer.lock 文件，你应该使用 update 命令。
php composer.phar update这将解决项目的所有依赖，并将确切的版本号写入 composer.lock。
如果你只是想更新几个包，你可以像这样分别列出它们：
php composer.phar update vendor/package vendor/package2你还可以使用通配符进行批量更新：
php composer.phar update vendor/*source 安装。dist 安装。require-dev 字段中列出的包（这是一个默认值）。require-dev 字段中列出的包。composer.json 文件中定义的脚本。require 命令增加新的依赖包到当前目录的 composer.json 文件中。
php composer.phar require在添加或改变依赖时， 修改后的依赖关系将被安装或者更新。
如果你不希望通过交互来指定依赖包，你可以在这条令中直接指明依赖包。
php composer.phar require vendor/package:2.* vendor/package2:dev-mastersource 安装。dist 安装。require-dev 字段中列出的包。global 命令允许你在 COMPOSER_HOME 目录下执行其它命令，像 install、require 或 update。
并且如果你将 $COMPOSER_HOME/vendor/bin 加入到了 $PATH 环境变量中，你就可以用它在命令行中安装全局应用，下面是一个例子：
php composer.phar global require fabpot/php-cs-fixer:dev-master现在 php-cs-fixer 就可以在全局范围使用了（假设你已经设置了你的 PATH）。如果稍后你想更新它，你只需要运行 global update：
php composer.phar global updatesearch 命令允许你为当前项目搜索依赖包，通常它只搜索 packagist.org 上的包，你可以简单的输入你的搜索条件。
php composer.phar search monolog您也可以通过传递多个参数来进行多条件搜索。
列出所有可用的软件包，你可以使用 show 命令。
php composer.phar show如果你想看到一个包的详细信息，你可以输入一个包名称。
php composer.phar show monolog/monologname : monolog/monologversions : master-dev, 1.0.2, 1.0.1, 1.0.0, 1.0.0-RC1type : librarynames : monolog/monologsource : [git] http://github.com/Seldaek/monolog.git 3d4e60d0cbc4b888fe5ad223d77964428b1978dadist : [zip] http://github.com/Seldaek/monolog/zipball/3d4e60d0cbc4b888fe5ad223d77964428b1978da 3d4e60d0cbc4b888fe5ad223d77964428b1978dalicense : MITautoloadpsr-0Monolog : src/requiresphp >=5.3.0你甚至可以输入一个软件包的版本号，来显示该版本的详细信息。
php composer.phar show monolog/monolog 1.0.2depends 命令可以查出已安装在你项目中的某个包，是否正在被其它的包所依赖，并列出他们。
php composer.phar depends --link-type=require monolog/monolognrk/monolog-fluentpoc/pocpropel/propelsymfony/monolog-bridgesymfony/symfonyrequire 也可以是 require-dev。在提交 composer.json 文件，和创建 tag 前，你应该始终运行 validate 命令。它将检测你的 composer.json 文件是否是有效的
php composer.phar validate如果你经常修改依赖包里的代码，并且它们是从 source（自定义源）进行安装的，那么 status 命令允许你进行检查，如果你有任何本地的更改它将会给予提示。
php composer.phar status你可以使用 --verbose 系列参数（-v|vv|vvv）来获取更详细的详细：
php composer.phar status -vYou have changes in the following dependencies:vendor/seld/jsonlint: M README.mdown将 Composer 自身升级到最新版本，只需要运行 self-update 命令。它将替换你的 composer.phar 文件到最新版本。
php composer.phar self-update如果你想要升级到一个特定的版本，可以这样简单的指定它：
php composer.phar self-update 1.0.0-alpha7如果你已经为整个系统安装 Composer（参见 全局安装），你可能需要在 root 权限下运行它：
sudo composer self-updateconfigconfig 命令允许你编辑 Composer 的一些基本设置，无论是本地的 composer.json 或者全局的 config.json 文件。
php composer.phar config --listconfig [options] [setting-key] [setting-value1] ... [setting-valueN]
setting-key 是一个配置选项的名称，setting-value1 是一个配置的值。可以使用数组作为配置的值（像 github-protocols），多个 setting-value 是允许的。
有效的配置选项，请查看“架构”章节的 config 。
$COMPOSER_HOME/config.json 的全局配置文件。如果不指定该参数，此命令将影响当前项目的 composer.json 文件，或 --file 参数所指向的文件。--global 参数时，将会打开全局 composer.json 文件。setting-key 指定名称的配置选项。--global 参数时，将会显示全局配置选项的列表。--global 参数一起使用。除了修改配置选项， config 命令还支持通过以下方法修改来源信息：
php composer.phar config repositories.foo vcs http://github.com/foo/bar你可以使用 Composer 从现有的包中创建一个新的项目。这相当于执行了一个 git clone 或 svn checkout 命令后将这个包的依赖安装到它自己的 vendor 目录。
此命令有几个常见的用途：
要创建基于 Composer 的新项目，你可以使用 "create-project" 命令。传递一个包名，它会为你创建项目的目录。你也可以在第三个参数中指定版本号，否则将获取最新的版本。
如果该目录目前不存在，则会在安装过程中自动创建。
php composer.phar create-project doctrine/orm path 2.2.*此外，你也可以无需使用这个命令，而是通过现有的 composer.json 文件来启动这个项目。
默认情况下，这个命令会在 packagist.org 上查找你指定的包。
composer 资源库的 HTTP URL，或者是指向某个 packages.json 文件的本地路径。stable。source 安装。dist 安装。require-dev 字段中列出的包。某些情况下你需要更新 autoloader，例如在你的包中加入了一个新的类。你可以使用 dump-autoload 来完成，而不必执行 install 或 update 命令。
此外，它可以打印一个优化过的，符合 PSR-0/4 规范的类的索引，这也是出于对性能的可考虑。在大型的应用中会有许多类文件，而 autoloader 会占用每个请求的很大一部分时间，使用 classmaps 或许在开发时不太方便，但它在保证性能的前提下，仍然可以获得 PSR-0/4 规范带来的便利。
列出已安装的每个包的名称、版本、许可协议。可以使用 --format=json 参数来获取 JSON 格式的输出。
你可以运行此命令来手动执行 脚本，只需要指定脚本的名称，可选的 --no-dev 参数允许你禁用开发者模式。
如果你觉得发现了一个 bug 或是程序行为变得怪异，你可能需要运行 diagnose 命令，来帮助你检测一些常见的问题。
php composer.phar diagnose此命令用来对指定包的指定版本进行 zip/tar 归档。它也可以用来归档你的整个项目，不包括 excluded/ignored（排除/忽略）的文件。
php composer.phar archive vendor/package 2.0.21 --format=zip使用 help 可以获取指定命令的帮助信息。
php composer.phar help install你可以设置一些环境变量来覆盖默认的配置。建议尽可能的在 composer.json 的 config 字段中设置这些值，而不是通过命令行设置环境变量。值得注意的是环境变量中的值，将始终优先于 composer.json 中所指定的值。
环境变量 COMPOSER 可以为 composer.json 文件指定其它的文件名。
例如：
COMPOSER=composer-other.json php composer.phar install通过设置这个环境变量，你可以指定 root 包的版本，如果程序不能从 VCS 上猜测出版本号，并且未在 composer.json 文件中申明。
通过设置这个环境变量，你可以指定 composer 将依赖安装在 vendor 以外的其它目录中。
通过设置这个环境变量，你可以指定 bin（Vendor Binaries）目录到 vendor/bin 以外的其它目录。
如果你是通过 HTTP 代理来使用 Composer，你可以使用 http_proxy 或 HTTP_PROXY 环境变量。只要简单的将它设置为代理服务器的 URL。许多操作系统已经为你的服务设置了此变量。
建议使用 http_proxy（小写）或者两者都进行定义。因为某些工具，像 git 或 curl 将使用 http_proxy 小写的版本。另外，你还可以使用 git config --global http.proxy <proxy url> 来单独设置 git 的代理。
如果你是使用代理服务器，并且想要对某些域名禁用代理，就可以使用 no_proxy 环境变量。只需要输入一个逗号相隔的域名 排除 列表。
此环境变量接受域名、IP 以及 CIDR地址块。你可以将它限制到一个端口（例如：:80）。你还可以把它设置为 * 来忽略所有的 HTTP 代理请求。
如果你使用了 HTTP 代理，但它不支持 request_fulluri 标签，那么你应该设置这个环境变量为 false 或 0 ，来防止 composer 从 request_fulluri 读取配置。
如果你使用了 HTTPS 代理，但它不支持 request_fulluri 标签，那么你应该设置这个环境变量为 false 或 0 ，来防止 composer 从 request_fulluri 读取配置。
COMPOSER_HOME 环境变量允许你改变 Composer 的主目录。这是一个隐藏的、所有项目共享的全局目录（对本机的所有用户都可用）。
它在各个系统上的默认值分别为：
/home/<user>/.composer。/Users/<user>/.composer。C:Users<user>AppDataRoamingComposer。你可以在 COMPOSER_HOME 目录中放置一个 config.json 文件。在你执行 install 和 update 命令时，Composer 会将它与你项目中的 composer.json 文件进行合并。
若 全局 和 项目 存在相同配置项，那么项目中的 composer.json 文件拥有更高的优先级。
COMPOSER_CACHE_DIR 环境变量允许你设置 Composer 的缓存目录，这也可以通过 cache-dir 进行配置。
它在各个系统上的默认值分别为：
$COMPOSER_HOME/cache。C:Users<user>AppDataLocalComposer 或 %LOCALAPPDATA%/Composer。这个环境变量控制着 Composer 执行命令的等待时间（例如：git 命令）。默认值为300秒（5分钟）。
这个环境变量控制着 discard-changes config option。
如果设置为1，这个环境变量将使 Composer 在执行每一个命令时都放弃交互，相当于对所有命令都使用了 --no-interaction。可以在搭建 虚拟机/持续集成服务器 时这样设置。
本章将解释包和库的概念，什么样的存储库是可用的，以及它们如何工作。
在此之前，我们看到存在不同类型的资源库，我们需要了解一些基本概念，以理解 Composer 是如何构建于其上的。
Composer 是一个依赖管理工具。它在本地安装一些资源包。一个包本质上就是一个包含东西的目录。通常情况下它存储 PHP 代码，但在理论上它可以是任何东西。并且它包含一个描述，其中有一个名称和一个版本号，这个名称和版本号用于识别该包。
事实上，在 composer 内部将每一个版本都视为一个单独的包。尽管在你使用 composer 时这种区别无关紧要，但当你想改变它时，这就显得至关重要。
除了名称和版本号，还存放了有用的元数据。与安装关系最密切的是 source 信息，它申明了在哪里可以获得资源包的内容。包数据指向包内容，并有两种指向方式：dist 和 source。
Dist: dist 指向一个存档，该存档是对一个资源包的某个版本的数据进行的打包。通常是已经发行的稳定版本。
Source: source 指向一个开发中的源。这通常是一个源代码仓库，例如 git。当你想要对下载下来的资源包进行修改时，可以这样获取。
你可以使用其中任意一个，或者同时使用。这取决于其它的一些因素，比如“user-supplied 选项”和“包的稳定性”，前者将会被优先考虑。
一个资源库是一个包的来源。它是一个 packages/versions 的列表。Composer 将查看所有你定义的 repositories 以找到你项目需要的资源包。
默认情况下已经将 Packagist.org 注册到 Composer。你可以在 composer.json 中申明更多的资源库，把它们加入你的项目中。
资源库的定义仅可用于“root 包”，而在你依赖的包中定义的资源库将不会被加载。如果你想了解其中的原因，请阅读 FAQ entry。
主资源库的类型为 composer。它使用一个单一的 packages.json 文件，包含了所有的资源包元数据。
这也是 packagist.org 所使用的资源类型。要引用一个 composer 资源库，只需要提供一个存放 packages.json 文件的 目录路径。比如要引用 packagist.org 下的 /packages.json，它的 URL 就应该是 packagist.org。而 example.org/packages.json 的 URL 应该是 example.org。
唯一必须的字段是 packages。它的 JSON 结构如下：
{ "packages": { "vendor/package-name": { "dev-master": { @composer.json }, "1.0.x-dev": { @composer.json }, "0.0.1": { @composer.json }, "1.0.0": { @composer.json } } }}@composer.json 标记将会从此包的指定版本中读取 composer.json 的内容，其内至少应包含以下信息：
这是一个最简单的包定义：
{ "name": "smarty/smarty", "version": "3.1.7", "dist": { "url": "http://www.smarty.net/files/Smarty-3.1.7.zip", "type": "zip" }}它还可以包含任何在 composer.json 架构 中介绍的字段。
notify-batch 字段允许你指定一个 URL，它将会在用户安装每一个包时被调用。该 URL 可以是（与其资源库相同域名的）绝对路径或者一个完整的 URL 地址。
例如使用下面的值：
{ "notify-batch": "/downloads/"}对于 example.org/packages.json 包含的 monolog/monolog 包，它将会发送一个 POST 请求到 example.org/downloads/，使用下面的 JSON request body：
{ "downloads": [ {"name": "monolog/monolog", "version": "1.2.1.0"}, ]}version 字段将包含标准化的版本号。
notify-batch 字段是可选的。
对于较大的资源库，可以拆分 packages.json 为多个文件。includes 字段允许你引用这些额外的文件。
实例：
{ "includes": { "packages-2011.json": { "sha1": "525a85fb37edd1ad71040d429928c2c0edec9d17" }, "packages-2012-01.json": { "sha1": "897cde726f8a3918faf27c803b336da223d400dd" }, "packages-2012-02.json": { "sha1": "26f911ad717da26bbcac3f8f435280d13917efa5" } }}文件的 SHA-1 码允许它被缓存，仅在 hash 值改变时重新请求。
此字段是可选的。你也许并不需要它来自定义存储库。
的对于非常大的资源库，像 packagist.org 使用 so-called provider 文件是首选方法。provider-includes 字段允许你设置一个列表，来申明这个资源库提供的包名称。在这种情况下文件的哈希算法必须使用 sha256。
providers-url 描述了如何在服务器上找到这些 provider 文件。它是以资源库的根目录为起点的绝对路径。
实例：
{ "provider-includes": { "providers-a.json": { "sha256": "f5b4bc0b354108ef08614e569c1ed01a2782e67641744864a74e788982886f4c" }, "providers-b.json": { "sha256": "b38372163fac0573053536f5b8ef11b86f804ea8b016d239e706191203f6efac" } }, "providers-url": "/p/%package%$%hash%.json"}这些文件包含资源包的名称以及哈希值，以验证文件的完整性，例如：
{ "providers": { "acme/foo": { "sha256": "38968de1305c2e17f4de33aea164515bc787c42c7e2d6e25948539a14268bb82" }, "acme/bar": { "sha256": "4dd24c930bd6e1103251306d6336ac813b563a220d9ca14f4743c032fb047233" } }}上述文件申明了 acme/foo 和 acme/bar 可以在这个资源库找到，通过加载由 providers-url 引用的文件，替换 %package% 为包名并且替换 %hash% 为 sha256 的值。这些文件本身只包含上文提到的 packages 的定义。
这些字段是可选的。你也许并不需要它们来自定义存储库。
packages.json 文件是用一个 PHP 流加载的。你可以使用 options 参数来设定额外的流信息。你可以设置任何有效的PHP 流上下文选项。更多相关信息请查看 Context options and parameters。
VCS 表示版本控制系统。这包括像 git、svn 或 hg 这样的版本管理系统。Composer 有一个资源类型可以从这些系统安装软件包。
这里有几个用例。最常见的是维护自己 fork 的第三方库。如果你在项目中使用某些库，并且你决定改变这些库内的某些东西，你会希望你项目中使用的是你自己的修正版本。如果这个库是在 GitHub 上（这种情况经常出现），你可以简单的 fork 它并 push 你的变更到这个 fork 里。在这之后你更新项目的 composer.json 文件，添加你的 fork 作为一个资源库，变更版本约束来指向你的自定义分支。关于版本约束的命名约定请查看 库（资源包）。
例如，假设你 fork 了 monolog，在 bugfix 分支修复了一个 bug：
{ "repositories": [ { "type": "vcs", "url": "https://github.com/igorw/monolog" } ], "require": { "monolog/monolog": "dev-bugfix" }}当你运行 php composer.phar update 时，你应该得到你修改的版本，而不是 packagist.org 上的 monolog/monolog。
注意，你不应该对包进行重命名，除非你真的打算摆脱原来的包，并长期的使用你自己的 fork。这样 Composer 就会正确获取你的包了。如果你确定要重命名这个包，你应该在默认分支（通常是 master 分支）上操作，而不是特性分支，因为包的名字取自默认分支。
如果其它包依赖你 fork 的这个分支，可能要对它做版本号的行内别名设置，才能够准确的识别版本约束。更多相关信息请查看 别名。
完全相同的解决方案，也可以让你使用你 GitHub 和 BitBucket 上的私人代码库进行工作：
{ "require": { "vendor/my-private-repo": "dev-master" }, "repositories": [ { "type": "vcs", "url": "git@bitbucket.org:vendor/my-private-repo.git" } ]}唯一的要求是为一个 git 客户端安装 SSH 秘钥。
Git 并不是 VCS 资源库唯一支持的版本管理系统。
以下几种都是被支持的：
为了从这些系统获取资源包，你必须安装对应的客户端，这可能是不方便的。基于这个原因，这里提供了 GitHub 和 BitBucket 的 API 的特殊支持，以便在无需安装版本控制系统的情况下获取资源包。在 VCS 资源库提供的 dist 中获取 zip 存档。
VCS 驱动将基于 URL 自动检测版本库类型。但如果可能，你需要明确的指定一个 git、svn 或 hg 作为资源库类型，而不是 vcs。
If you set the no-api key to true on a github repository it will clone the repository as it would with any other git repository instead of using the GitHub API. But unlike using the git driver directly, composer will still attempt to use github's zip files.
由于 Subversion 没有原生的分支和标签的概念，Composer 假设在默认情况下该代码位于 $url/trunk、$url/branches 和 $url/tags 内。如果你的存储库使用了不同的布局，你可以更改这些值。例如，如果你使用大写的名称，你可以像这样配置资源库：
{ "repositories": [ { "type": "vcs", "url": "http://svn.example.org/projectA/", "trunk-path": "Trunk", "branches-path": "Branches", "tags-path": "Tags" } ]}如果你的存储库目录中没有任何分支或标签文件夹，你可以将 branches-path 或 tags-path 设置为 false。
如果是一个位于子目录的包，例如， /trunk/foo/bar/composer.json 和 /tags/1.0/foo/bar/composer.json，那么你可以让 composer 通过 "package-path" 选项设置的子目录进行访问，在这个例子中可以将其设置为 "package-path": "foo/bar/"。
pear 类型资源库，使得从任何 PEAR 渠道安装资源包成为可能。Composer 将为所有此类型的包增加前缀（类似于 pear-{渠道名称}/）以避免冲突。而在之后使用别名时也增加前缀（如 pear-{渠道别名}/）。
例如使用 pear2.php.net：
{ "repositories": [ { "type": "pear", "url": "http://pear2.php.net" } ], "require": { "pear-pear2.php.net/PEAR2_Text_Markdown": "*", "pear-pear2/PEAR2_HTTP_Request": "*" }}在这种情况下渠道的简称（别名）是 pear2，因此 PEAR2_HTTP_Request 包的名称应该写作 pear-pear2/PEAR2_HTTP_Request。
注意：
pear类型的资源库对每个 requires 都要做完整的请求，因此可能大大降低安装速度。
通过自定义供应商名称，对 PEAR 渠道包进行别名是允许的。
例：
假设你有一个私人 PEAR 库，并希望使用 Composer 从 VCS 集成依赖。你的 PEAR 库包含以下资源包：
BasePackage。IntermediatePackage 依赖于 BasePackage。TopLevelPackage1 和 TopLevelPackage2 都依赖于 IntermediatePackage。如果没有一个供应商别名，Composer 将使用 PEAR 渠道名称作为包名的一部分：
pear-pear.foobar.repo/BasePackagepear-pear.foobar.repo/IntermediatePackagepear-pear.foobar.repo/TopLevelPackage1pear-pear.foobar.repo/TopLevelPackage2假设之后的某个时间，你希望将你的 PEAR 包迁移，使用 Composer 资源库和命名方案，并且采用 foobar 作为供应商名称。这样之前使用 PEAR 包的项目将不会看到更新的资源包，因为它们有不同的供应商名称（foobar/IntermediatePackage 与 pear-pear.foobar.repo/IntermediatePackage）。
你可以通过从一开始就为 PEAR 资源库指定 vendor-alias 来避免这种情况的发生，以得到一个不会过时的包名。
为了说明这一点，下面的例子会从你的 PEAR 资源库中得到 BasePackage、TopLevelPackage1 和 TopLevelPackage2 资源包，并从 Github 资源库中获取 IntermediatePackage 资源包：
{ "repositories": [ { "type": "git", "url": "https://github.com/foobar/intermediate.git" }, { "type": "pear", "url": "http://pear.foobar.repo", "vendor-alias": "foobar" } ], "require": { "foobar/TopLevelPackage1": "*", "foobar/TopLevelPackage2": "*" }}如果你想使用一个项目，它无法通过上述任何一种方式支持 composer，你仍然可以使用 package 类型定义资源库。
基本上，你可以定义与 packages.json 中 composer 类型资源库相同的信息，但需要为每个这样的资源包分别定义。同样，至少应该包含以下信息：name、version、（dist 或 source）。
这是一个 smarty 模板引擎的例子：
{ "repositories": [ { "type": "package", "package": { "name": "smarty/smarty", "version": "3.1.7", "dist": { "url": "http://www.smarty.net/files/Smarty-3.1.7.zip", "type": "zip" }, "source": { "url": "http://smarty-php.googlecode.com/svn/", "type": "svn", "reference": "tags/Smarty_3_1_7/distribution/" }, "autoload": { "classmap": ["libs/"] } } } ], "require": { "smarty/smarty": "3.1.*" }}通常你不需要去定义 source，因为你并不是真的需要它。
注意： 该资源库类型存在以下限制，因此应尽可能避免使用：
- Composer 将不会更新资源包，除非你修改了
version字段。- Composer 将不会更新 commit references，因此如果你使用
masterreference，将不得不删除该程序包以强制更新，并且将不得不面对一个不稳定的 lock 文件。
尽管大部分的时间，你大概都会把资源包放在 packagist.org 上，但这里还将告诉你一些用例，以便你可以自行托管资源库。
Private company packages: 如果你是一个公司的职员，对公司内部的资源包使用 composer，你可能会想让这些包保持私有的状态。
对于自行托管的软件包，建议使用 composer 类型资源库设置，它将提供最佳的性能。
这里有一些工具，可以帮助你创建 composer 类型的资源库。
packagist 的底层是开源的。这意味着你可以只安装你自己拷贝的 packagist，改造并使用它。这真的是很直接简单的事情。然而，由于其规模和复杂性，对于大多数中小型企业还是建议使用 Satis。
Packagist 是一个 Symfony2 应用程序，并且托管在 GitHub 上 github.com/composer/packagist。它内部使用了 composer 并作为 VCS 资源库与 composer 用户之间的代理。它拥有所有 VCS 资源包的列表，定期重新抓取它们，并将其作为一个 composer 资源库。
要设置你的副本，只需要按照 github.com/composer/packagist 的说明进行操作。
Satis 是一个静态的 composer 资源库生成器。它像是一个超轻量级的、基于静态文件的 packagist 版本。
你给它一个包含 composer.json 的存储库，定义好 VCS 和 资源库。它会获取所有你列出的包，并打印 packages.json 文件，作为 composer 类型的资源库。
更多详细信息请查看 github.com/composer/satis 和 Satis article。
在某些情况下，或许没有能力拥有之前提到的任何一种线上资源库。Typical example could be cross-organisation library exchange through built artifacts。当然大部分的时间他们都是私有的。为了简化维护，可以简单的使用 artifact 资源库类型，来引用一个包含那些私有包的 ZIP 存档的文件夹：
{ "repositories": [ { "type": "artifact", "url": "path/to/directory/with/zips/" } ], "require": { "private-vendor-one/core": "15.6.2", "private-vendor-two/connectivity": "*", "acme-corp/parser": "10.3.5" }}每个 zip artifact 都只是一个 ZIP 存档，放置在 composer.json 所在的根目录：
unzip -l acme-corp-parser-10.3.5.zipcomposer.json...如果有两个不同版本的资源包，它们都会被导入。当有一个新版本的存档被添加到 artifact 文件夹，并且你运行了 update 命令，该版本就会被导入，并且 Composer 将更新到最新版本。
你可以在 composer.json 中禁用默认的 Packagist 资源库。
{ "repositories": [ { "packagist": false } ]}当你使用 VCS 资源库，你将只会得到类似于这样的版本号：从分支发布的标签获取，它看起来像 2.0 或 2.0.x。比较特殊的是，对于你的 master 分支，你会得到一个最新提交的 dev-master 版本。对于你的 bugfix 分支，你会得到一个最新提交的 dev-bugfix 版本。以此类推，这些特殊的版本标识可以用来获取最新的分支源码。
如果你的 master 分支使用标签发布了 1.0 系列版本，即 1.0.1、1.0.2、1.0.3 等等，任何依赖它的资源包都可能会使用 1.0.* 这个版本约束。
如果有人想要最新的 dev-master 版本，他们将会碰到一个问题：另一些依赖它的包可能使用了 1.0.* 这个版本约束，因此在 require 这个开发版本时将会产生冲突，因为 dev-master 不符合 1.0.* 的约束。
这时，就可以使用别名。
dev-master 指向一个在你 VCS 项目上的主分支。有些用户会想要使用最新的开发版本，这是相当常见的情况。因此，Composer 允许你别名你的 dev-master 版本为一个 1.0.x-dev 的版本号。这是通过在 composer.json 文件中的 extra 下指定 branch-alias 字段来完成的：
{ "extra": { "branch-alias": { "dev-master": "1.0.x-dev" } }}此处的分支版本必须以 dev- 开头（不可比较的版本名称），对应的别名必须是可比较的开发版本名称（即，以数字开头，并以 .x-dev 结束）。branch-alias 所引用的分支必须是存在的。对于 dev-master 你需要在 master 分支上提交它。
其结果是，任何人都可以使用 1.0.* 版本约束来得到 dev-master 版本。
为了定义分支别名，你必须是需要别名的包的所有者。如果你想别名一个第三方包，而又不想 fork 它到自己的版本库，可以使用行内别名，我们在接下来就会提到它。
分支别名是非常适合用于主开发分支的。但为了使用它们，你需要拥有对源码的控制权，并且你需要提交别名修改到你控制的版本库。
当你只想在本地项目中尝试一些依赖包的 bug 修正时，这并不是最好的方式。
出于这个原因，你可以在 require 和 require-dev 字段中直接别名你需要的包。比方说那你找到了 monolog/monolog 的一个 bug。你在 GitHub 上克隆了 Monolog 并在名为 bugfix 的分支上修正了一个问题。现在你想安装这个版本到你的本地项目。
你所使用的 symfony/monolog-bundle require 了 monolog/monolog 并约束了版本 1.*. 因此你需要让你的 dev-bugfix 满足该版本约束。
只要在你项目根目录的 composer.json 文件中加入以下内容：
{ "repositories": [ { "type": "vcs", "url": "https://github.com/you/monolog" } ], "require": { "symfony/monolog-bundle": "2.0", "monolog/monolog": "dev-bugfix as 1.0.x-dev" }}它将会在你的 GitHub 上获取 monolog/monolog 的 dev-bugfix 版本并将其版本别名为 1.0.x-dev。
注意： 如果要对一个资源包使用行内别名，这个别名（
as的右边）必须能够使用版本约束。as左边的部分在这之后将被丢弃。因此，如果 A 依赖 B 而 B 又依赖monolog/monolog且版本约束为dev-bugfix as 1.0.x-dev，那么安装 A 时将使用 B 的版本约束，并识别为1.0.x-dev，此时必须真实存在一个“分支别名”或“1.0 系列分支”。否则就必须在 A 的composer.json文件中再次定义行内别名。注意： 应该尽量避免行内别名，特别是对已经发布的包。如果你发现了一个 bug，请尝试将你的修复合并到上游分支。这将避免使用你资源包的用户出现问题。
有时需要在包的安装过程中执行其它的动作，例如：将它安装在默认的 vendor 以外的其它目录。
在这些情况下，你可以考虑创建一个自定义安装程序来处理特定的逻辑。
假设你的项目已经有了一个自定义的安装模块，那么如何根据 安装类型 正确调用你包文件中的安装程序就成为了一个问题。
参见见下一章，如何通过指令创建自定义安装程序。
任何自定义安装程序都要通过 type 属性来识别。一旦被确认，它将完全覆盖默认的安装程序，并执行自己的安装逻辑。
一个实际用例：
phpDocumentor 的特殊模板需要安装在 /vendor 以外的其它目录中。 因此他们选择 phpdocumentor-template 安装类型 并为此类型创建了一个插件，以便将他们的模板发送到正确的目录中。
在这样一个模板包的例子中 composer.json 将使用以下设置：
{ "name": "phpdocumentor/template-responsive", "type": "phpdocumentor-template", "require": { "phpdocumentor/template-installer-plugin": "*" }}重要提示： 为了确保这个模板安装程序在安装模板包之前就已存在，模板包必须写入对此安装程序包的依赖。
一个自定义安装程序通常是以 Composer 插件的形式存在，并包含有一个类，它实现了 ComposerInstallerInstallerInterface 这个接口。
一个基本的安装程序插件必须由3个文件组成：
MyProjectComposerPlugin.php，其中的类必须实现 ComposerPluginPluginInterface 接口。MyProjectComposerInstaller.php，其中的类必须实现 ComposerInstallerInstallerInterface 接口。此处的包文件和普通资源包是相同的，但需要满足以下条件：
实例：
{ "name": "phpdocumentor/template-installer-plugin", "type": "composer-plugin", "license": "MIT", "autoload": { "psr-0": {"phpDocumentorComposer": "src/"} }, "extra": { "class": "phpDocumentorComposerTemplateInstallerPlugin" }, "require": { "composer-plugin-api": "1.0.0" }}这个类定义了 Composer 的插件，它必须实现 ComposerPluginPluginInterface 这个接口。它可以在 activate() 方法中注册自定义安装程序。
这个类可以被放在任何位置、使用任何名字，只要能够根据 extra.class 中的定义被自动加载即可。
实例：
<?phpnamespace phpDocumentorComposer;use ComposerComposer;use ComposerIOIOInterface;use ComposerPluginPluginInterface;class TemplateInstallerPlugin implements PluginInterface{ public function activate(Composer $composer, IOInterface $io) { $installer = new TemplateInstaller($io, $composer); $composer->getInstallationManager()->addInstaller($installer); }}这个类用于执行自定义的安装过程，它必须实现 ComposerInstallerInstallerInterface 这个接口（或者继承了另一个实现此接口的安装程序类）。它将会对安装类型中定义的字符串执行 supports() 方法验证，一旦通过就采用对应的安装程序。
注意： 请慎重选择你的 安装类型 名称，建议遵循这样的格式：vendor-type。例如：phpdocumentor-template。
InstallerInterface 类定义了以下方法（请查阅源码以获得更详细的信息）：
实例：
<?phpnamespace phpDocumentorComposer;use ComposerPackagePackageInterface;use ComposerInstallerLibraryInstaller;class TemplateInstaller extends LibraryInstaller{ /** * {@inheritDoc} */ public function getPackageBasePath(PackageInterface $package) { $prefix = substr($package->getPrettyName(), 0, 23); if ('phpdocumentor/template-' !== $prefix) { throw new InvalidArgumentException( 'Unable to install template, phpdocumentor templates ' .'should always start their package name with ' .'"phpdocumentor/template-"' ); } return 'data/templates/'.substr($package->getPrettyName(), 23); } /** * {@inheritDoc} */ public function supports($packageType) { return 'phpdocumentor-template' === $packageType; }}这个例子演示了，简单的继承 ComposerInstallerLibraryInstaller 类来剥离 phpdocumentor/template- 前缀，并用剩余的部分重新组装了一个完全不同的安装路径。
并非安装在 /vendor 目录，任何使用这个安装程序的资源包，将被放置在 /data/templates/<stripped name> 目录中。
你可能需要改变和扩展 Composer 加入自定义的功能。例如：如果你的环境对 Composer 的行为有特殊要求，而这并不适用于普通用户。又或者，你想使用 Composer 完成某些事情，而又不希望对普通用户造成影响。
在这些情况下，你可以考虑创建一个插件来处理特定的逻辑。
一个插件就是一个普通的 Composer 资源包，插件的主要代码都位于这个包中，并且还可以依赖更多其它的资源包。
插件包内的文件和普通资源包相同，但必须满足下列要求：
此外，你必须 require 一个特殊的资源包 composer-plugin-api，定义与你的插件相兼容的 composer plugin API 版本。目前 composer plugin API 的版本为1.0.0。
实例：
{ "name": "my/plugin-package", "type": "composer-plugin", "require": { "composer-plugin-api": "1.0.0" }}每一个插件都必须提供一个实现了 ComposerPluginPluginInterface 接口的类。类中的 activate() 方法在插件载入后被调用，并接收两个类的实例：ComposerComposer 和 ComposerIOIOInterface。使用这两个对象可以读取所有的配置，操作所有的内部对象和状态。
实例：
<?phpnamespace phpDocumentorComposer;use ComposerComposer;use ComposerIOIOInterface;use ComposerPluginPluginInterface;class TemplateInstallerPlugin implements PluginInterface{ public function activate(Composer $composer, IOInterface $io) { $installer = new TemplateInstaller($io, $composer); $composer->getInstallationManager()->addInstaller($installer); }}此外，插件还可以实现 ComposerEventDispatcherEventSubscriberInterface 接口，为了在插件载入后自动注册事件处理程序到 EventDispatcher。
插件可用事件如下：
PRE_FILE_DOWNLOAD 在文件下载前被触发，它允许你在下载前根据目标 URL 操作 RemoteFilesystem 对象。
一个插件也可以订阅 脚本事件。
实例：
<?phpnamespace NadermanComposerAWS;use ComposerComposer;use ComposerEventDispatcherEventSubscriberInterface;use ComposerIOIOInterface;use ComposerPluginPluginInterface;use ComposerPluginPluginEvents;use ComposerPluginPreFileDownloadEvent;class AwsPlugin implements PluginInterface, EventSubscriberInterface{ protected $composer; protected $io; public function activate(Composer $composer, IOInterface $io) { $this->composer = $composer; $this->io = $io; } public static function getSubscribedEvents() { return array( PluginEvents::PRE_FILE_DOWNLOAD => array( array('onPreFileDownload', 0) ), ); } public function onPreFileDownload(PreFileDownloadEvent $event) { $protocol = parse_url($event->getProcessedUrl(), PHP_URL_SCHEME); if ($protocol === 's3') { $awsClient = new AwsClient($this->io, $this->composer->getConfig()); $s3RemoteFilesystem = new S3RemoteFilesystem($this->io, $event->getRemoteFilesystem()->getOptions(), $awsClient); $event->setRemoteFilesystem($s3RemoteFilesystem); } }}插件包是优先被安装和加载的，在 Composer 启动时，如果在已安装资源包的当前项目列表中被找到，它们将被自动加载。此外，所有的插件包将被安装在 COMPOSER_HOME 目录，以便在 Composer 全局命令前载入，在操作本地项目前插件就已经被载入。
你可以通过 --no-plugins 选项让 composer 的命令禁用所有已经安装的插件。这或许是特别有用的，如果任何插件会导致错误，而你想要升级或卸载它。
一个脚本，在 Composer 中，可以是一个 PHP 回调（定义为静态方法）或任何命令行可执行的命令。脚本对于在 Composer 运行过程中，执行一个资源包的自定义代码或包专用命令是非常有用的。
注意：只有在根包的 composer.json 中定义的脚本才会被执行。即便根包的外部依赖定义了其自身的脚本，Composer 也不会去执行这些额外的脚本。
Composer 在运行过程中将会触发以下事件：
| 事件名称 | 详细说明 |
|---|---|
| **pre-install-cmd** | 在 `install` 命令执行前触发。 |
| **post-install-cmd** | 在 `install` 命令执行后触发。 |
| **pre-update-cmd** | 在 `update` 命令执行前触发。 |
| **post-update-cmd** | 在 `update` 命令执行后触发。 |
| **pre-status-cmd** | 在 `status` 命令执行前触发。 |
| **post-status-cmd** | 在 `status` 命令执行后触发。 |
| **pre-package-install** | 在资源包安装前触发。 |
| **post-package-install** | 在资源包安装后触发。 |
| **pre-package-update** | 在资源包更新前触发。 |
| **post-package-update** | 在资源包更新后触发。 |
| **pre-package-uninstall** | 在资源包被卸载前触发。 |
| **post-package-uninstall** | 在资源包被卸载后触发。 |
| **pre-autoload-dump** | 在自动加载器被转储前触发，无论是 `install`/`update` 还是 `dump-autoload` 命令都会触发。 |
| **post-autoload-dump** | 在自动加载器被转储后触发，无论是 `install`/`update` 还是 `dump-autoload` 命令都会触发。 |
| **post-root-package-install** | 在 `create-project` 命令期间，根包安装完成后触发。 |
| **post-create-project-cmd** | 在 `create-project` 命令执行后触发。 |
archive command is executed.post-archive-cmd: occurs after the archive command is executed.
注意：Composer 不会去执行任何依赖包中定义的 install 或 update 相关脚本。因此你不应该在依赖包中申明 pre-update-cmd 或 pre-install-cmd。如果你需要在执行 install 或 update 命令前使用脚本，请确保它们已被定义在根包中。
在 composer.json 的根 JSON 对象中应该有一个名为 "scripts" 的属性，它包含有一系列的事件名称，以及对应的事件脚本。一个事件的脚本可以被定义为一个字符串（仅适用于单个脚本）或数组（单个或多个脚本）。
对于任何给定的事件：
脚本定义实例：
{ "scripts": { "post-update-cmd": "MyVendorMyClass::postUpdate", "post-package-install": [ "MyVendorMyClass::postPackageInstall" ], "post-install-cmd": [ "MyVendorMyClass::warmCache", "phpunit -c app/" ] }}使用前面定义的例子，这里的 MyVendorMyClass 类，就可以被使用来执行 PHP 的回调：
<?phpnamespace MyVendor;use ComposerScriptEvent;class MyClass{ public static function postUpdate(Event $event) { $composer = $event->getComposer(); // do stuff } public static function postPackageInstall(Event $event) { $installedPackage = $event->getOperation()->getPackage(); // do stuff } public static function warmCache(Event $event) { // make cache toasty }}当一个事件被触发，Composer 的内部事件处理程序将接收一个 ComposerScriptEvent 对象，这是传递给您的 PHP 回调的第一个参数。这个 Event 对象拥有一些 getter 方法来帮助你取得当前事件的上下文：
getComposer(): 返回当前的 ComposerComposer 对象实例。getName(): 返回事件名称的字符串。getIO(): 返回当前的 输入输出 流，它实现了 ComposerIOIOInterface 接口，以便在控制台中使用。如果你想手动运行事件脚本，可以使用下面的语法结构：
composer run-script [--dev] [--no-dev] script例如 composer run-script post-install-cmd 将会运行所有 post-install-cmd 事件下定义的脚本。
vendor/bin 目录一个 Composer 资源包，想要传递给安装它的用户的任何命令行脚本， 都应该被列入 二进制供应库。
如果一个资源包，含有不被用户所需要的其他脚本（比如构建或编译脚本） 那么这些代码不应该被列入二进制供应库。
它是通过在项目的 composer.json 里添加一个 bin 键定义的。 它是以一种文件的数组的形式定义的，这样任何给定的项目 都可以添加多个二进制文件。
{ "bin": ["bin/my-script", "bin/my-other-script"]}对于任何 依赖于 该资源包的项目， 它将引导 Composer 安装资源包里的二进制文件到 vendor/bin 目录。
这是一个便捷的途径来暴露有用的脚本， 否则它们将会被隐藏在 vendor/ 目录的深处。
对于被某个资源包直接定义的二进制供应库，什么也不会发生。
Composer 会检查所有依赖包里定义的二进制文件。 并为每一个依赖的二进制库设立一个指向 vendor/bin 的软连接。
比如 my-vendor/project-a 资源包的二进制库就是这样安装的：
{ "name": "my-vendor/project-a", "bin": ["bin/project-a-bin"]}在该 composer.json 上执行 composer install 命令， 不会对 bin/project-a-bin 造成任何影响。
再比如项目 my-vendor/project-b 有这样的 require 定义：
{ "name": "my-vendor/project-b", "require": { "my-vendor/project-a": "*" }}在该 composer.json 上执行 composer install 命令时， 将会检查 project-b 的所有依赖包，并安装它们的二进制库到 vendor/bin 目录。
这种情况下，Composer 将使 vendor/bin/project-a-bin 可以作为 vendor/my-vendor/project-a/bin/project-a-bin 的访问路径。在类 Unix 平台上， 这是通过创建软链接实现的。
完全由 Composer 管理的包并不 需要 包含任何用以兼容 Windows 的 .bat 文件。在 Windows 环境下运行时，Composer 会用一种特殊的方式处理 二进制文件的安装：
.bat 文件会自动生成有时资源包需要维护自定义的 .bat 文件来支持工作流，它可以不包含在 Composer 中。 这种情况下，该资源包 不 应该把它们作为二进制文件列出，因为 Composer 不需要知道它们。
当然，这里有两种指定二进制供应库的其他可选位置的方法：
composer.json 文件中的 bin-dir 配置属性处设置COMPOSER_BIN_DIR前者的实例如下：
{ "config": { "bin-dir": "scripts" }}在这个 composer.json 上运行 composer install 会把所有的二进制供应库 都安装在 scripts/ 目录，而不是缺省的 vendor/bin/ 目录。
对于现代语言而言，包管理器基本上是标配。Java有Maven，Python有pip，Ruby有gem，Nodejs有npm。PHP的则是PEAR，不过PEAR坑不少：
好在我们有Composer，PHP依赖管理的利器。它是开源的，使用起来也很简单，提交自己的包也很容易。
Composer需要PHP 5.3.2+才能运行。
$ curl -sS https://getcomposer.org/installer | php这个命令会将composer.phar下载到当前目录。PHAR（PHP 压缩包）是一个压缩格式，可以在命令行下直接运行。
你可以使用--install-dir选项将Composer安装到指定的目录，例如：
$ curl -sS https://getcomposer.org/installer | php -- --install-dir=bin当然也可以进行全局安装：
$ curl -sS https://getcomposer.org/installer | php$ mv composer.phar /usr/local/bin/composer在Mac OS X下也可以使用homebrew安装：
brew tap josegonzalez/homebrew-php brew install josegonzalez/php/composer 不过通常情况下只需将composer.phar的位置加入到PATH环境变量就可以，不一定要全局安装。
在项目目录下创建一个composer.json文件，指明依赖，比如，你的项目依赖 monolog：
{ "require": { "monolog/monolog": "1.2.*" }}安装依赖非常简单，只需在项目目录下运行：
composer install 如果没有全局安装的话，则运行：
php composer.phar install Composer提供了自动加载的特性，只需在你的代码的初始化部分中加入下面一行：
require 'vendor/autoload.php'; packagist.org是Composer的仓库，很多著名的PHP库都能在其中找到。你也可以提交你自己的作品。
以上介绍了Composer 的基本用法。Composer还有一些高级特性，虽然不是必需的，但是往往能给PHP开发带来方便。
每个框架都可能有一个或多个不同的依赖包安装目录。Composer 可以通过使用 composer/installers 来配置，安装依赖到其它的目录，而不是默认的 vendor 目录。
如果你是一个 包作者 并且希望自己的资源包被安装到自定义的目录中，简单的 require composer/installers 依赖，并设置适当的 type 属性。这是常见的方式，如果你的资源包专门用于一个框架，如 CakePHP、Drupal 或 WordPress。这是一个 WordPress 主题的 composer.json 文件的例子：
{ "name": "you/themename", "type": "wordpress-theme", "require": { "composer/installers": "~1.0" }}现在当你用 Composer 安装这个主题时，它就会被放置在 wp-content/themes/themename/ 目录。目前已被支持的 type 类型请查看 current supported types。
对于一个 包使用者 你可以为一个包设置或覆盖安装路径，requires composer/installers 并在 extra 下设置 installer-paths 属性。Drupal 的多站点设置就是一个很好的例子，其中的资源包应该被安装到各自网站的子目录。在这里我们使用 composer/installers 来覆盖安装路径：
{ "extra": { "installer-paths": { "sites/example.com/modules/{$name}": ["vendor/package"] } }}现在该资源包将被安装到你指定的目录，并替换 $name 变量，而不是默认目录。
注意： 你不能通过它改变所有包的安装目录。这仅适用于引入
composer/installers依赖，自定义了 type 属性的资源包。
一般情况下 不建议。vendor 目录（或者你安装依赖的其它目录）都应该被添加进 .gitignore/svn:ignore/等等。
最好这么做，然后让所有开发人员使用 Composer 来安装依赖包。同样，build server、CI、deployment tools 等等，应进行修改，使运行 Composer 成为其项目引导的一部分。
虽然在某些环境下提交它是很让人心动的，但它将导致一些问题：
如果你真的觉得你必须这样做，你有几个选择：
preferred-install 为 dist。.git 文件夹，然后你就可以添加它们到你的 git repo 中。你可以运行 rm -rf vendor/**/.git 命令快捷的操作，但这意味着你在运行 composer update 命令前需要先删除磁盘中的依赖文件。vendor/.git）来忽略 vendor 下所有 .git 目录。这种方法不需要你在运行 composer update 命令前删除你磁盘中的依赖文件。无明确目标
首先来看看这个项目：https://github.com/Ricardo-Li/node-practice-3
（图1）
类似这样的 badges，在很多项目中都可以看到。前者是告诉我们，这个项目的测试目前是通过的；后者是告诉我们，这个测试的行覆盖率是多少。行覆盖率当然是越多越好。测试的重要性我就不说了。
为什么要使用 travis 这样的平台，是因为它可以让你明白自己的项目在一个“空白环境”中，是否能正确运行；也可以让你知道，用不同的 Node.js 版本运行的话，有没有兼容性问题。
当你在自己的机器上跑测试的时候，你用着特定的 Node.js 版本，比如 0.10，如果测试过了，你也还是不懂在 0.11 下，你的测试能不能通过。你可以手动地切换 node 版本再跑一次，也可以选择让 travis 帮你把不同的 node 版本跑一次。而且有时候，我们 npm 安装了某个包，但却忘记将它写入 package.json 里面了，在自己的机器上，测试没问题，但当别的用户安装你的包时，会发现有依赖缺失。
travis 应该是把虚拟机的技术玩得比较好，它每次跑测试时，都会提供一个空白的环境。这个环境只有 Linux 基本的 build-essential 和 wget、git 那些依赖。连 Node.js 的运行时都是现跑现安装的。
travis 默认带有的那些依赖，都是每个用户的机器上都会有的，所以一旦你的应用在 travis 上面能够跑通，那么就不用担心别的用户安装不上了。
我们来讲讲接入 travis 的步骤。
travis 的价格是免费的，对于 github 上的开源项目来说。它默认当然不可能帮 github 的每个用户都跑测试，所以你需要去注册一下 travis，然后告诉它你需要开启集成测试的仓库。
比如上图，可以看到我帮自己的 alsohosts 项目以及 adsf 项目开启了测试。
当你在 travis 授权了仓库之后，每当你 push 代码到 github，travis 都会自动帮你跑测试。
travis 通过授权，可以知道你的项目在什么地方，于是它就可以把项目 clone 过去。但问题又来了，它不懂你的测试怎么跑啊。用 npm test 还是 make test 还是 jake test 呢？
所以我们需要给出一些配置信息，配置信息以 .travis.yml 文件的形式放在项目根目录，比如一个简单的 .travis.yml。
language: node_jsnode_js: - '0.8' - '0.10' - '0.11'script: make test这个文件传递的信息是：
make test将这个文件添加到项目的根目录下，再 push 上 github，这时候 travis 就会被触发了。
travis 接着会做的事情是：
npm install 来安装依赖。make test如果测试通过的话，make 命令的返回码会是 0（如果不懂什么是返回码，则需要补补 shell 的知识），则测试通过；如果测试有不通过的 case，则返回码不会为 0，travis 则判断测试失败。
每一个 travis 上面的项目，都可以得到一个图片地址，这个地址上的图片会显示你项目当前的测试通过状态，把这个图片添加到自己项目的 README 中，就可以得到我们图1的那种逼格了。
对了，行覆盖率的那个 badge 是由一个叫 coveralls(https://coveralls.io/ ) 的服务提供的。大家可以试着自己接入。
如果你的应用有使用到数据库, 需要在 .travis.yml 中添加一些内容.
以 MongoDB 为例:
services: mongodb其它数据库详细内容参考travis 官方文档
当你使用自定义库时，你可能会碰到问题，因为 Composer 不会递归加载你要求的储存库，所以你必须修改这些储存库中所有的 composer.json 文件。
在详细说明为什么是这样之前，你需要明白：使用自定义 VCS & 包储存库去尝试某些事情，或者使用你 fork 的一个分支，直到你的 pull request 被合并，等等。你不应该使用它们来跟踪你的私人资源包，关于这点你应该看看 setting up Satis 来为你的公司甚至自己处理私人资源包。
这里有三个途径可以使依赖解析器使用你自定义的储存库：
读取根包的存储库，从定义的存储库得到所有的软件包，解析依赖需求。这是目前的状态，它工作得很好，除了有“无法递归的加载储存库”这个限制。
读取根包的存储库，同时从定义的 repos 初始化资源包，递归的初始化，根据所有依赖包中定义的 repos，以及这些依赖包所依赖的其它包中定义的 repos，等等，然后再解析依赖需求。这可能可以工作，但会严重影响初始化的速度，因为每读取一个 VCS repos 都需要几秒钟。它可能最终执行失败，因为一个包的不同版本，可能来自一个包资源库中一个相同的包，但来至不同的 dist/source 。这样有太多的可能会出错。
Composer 是 PHP 的一个依赖管理工具。它允许你申明项目所依赖的代码库，它会在你的项目中为你安装他们。
Composer 不是一个包管理器。是的，它涉及 "packages" 和 "libraries"，但它在每个项目的基础上进行管理，在你项目的某个目录中（例如 vendor）进行安装。默认情况下它不会在全局安装任何东西。因此，这仅仅是一个依赖管理。
这种想法并不新鲜，Composer 受到了 node's [npm][1] 和 ruby's [bundler][2] 的强烈启发。而当时 PHP 下并没有类似的工具。
Composer 将这样为你解决问题：
a) 你有一个项目依赖于若干个库。
b) 其中一些库依赖于其他库。
c) 你声明你所依赖的东西。
d) Composer 会找出哪个版本的包需要安装，并安装它们（将它们下载到你的项目中）。
比方说，你正在创建一个项目，你需要一个库来做日志记录。你决定使用 [monolog][3]。为了将它添加到你的项目中，你所需要做的就是创建一个 composer.json 文件，其中描述了项目的依赖关系。
{ "require": { "monolog/monolog": "1.2.*" }}我们只要指出我们的项目需要一些 monolog/monolog 的包，从 1.2 开始的任何版本。
运行 Composer 需要 PHP 5.3.2+ 以上版本。一些敏感的 PHP 设置和编译标志也是必须的，但对于任何不兼容项安装程序都会抛出警告。
我们将从包的来源直接安装，而不是简单的下载 zip 文件，你需要 git 、 svn 或者 hg ，这取决于你载入的包所使用的版本管理系统。
Composer 是多平台的，我们努力使它在 Windows 、 Linux 以及 OSX 平台上运行的同样出色。
要真正获取 Composer，我们需要做两件事。首先安装 Composer （同样的，这意味着它将下载到你的项目中）：
curl -sS https://getcomposer.org/installer | php注意： 如果上述方法由于某些原因失败了，你还可以通过 php >下载安装器：
php -r "readfile('https://getcomposer.org/installer');" | php这将检查一些 PHP 的设置，然后下载 composer.phar 到你的工作目录中。这是 Composer 的二进制文件。这是一个 PHAR 包（PHP 的归档），这是 PHP 的归档格式可以帮助用户在命令行中执行一些操作。
你可以通过 --install-dir 选项指定 Composer 的安装目录（它可以是一个绝对或相对路径）：
curl -sS https://getcomposer.org/installer | php -- --install-dir=bin你可以将此文件放在任何地方。如果你把它放在系统的 PATH 目录中，你就能在全局访问它。 在类Unix系统中，你甚至可以在使用时不加 php 前缀。
你可以执行这些命令让 composer 在你的系统中进行全局调用：
curl -sS https://getcomposer.org/installer | phpmv composer.phar /usr/local/bin/composer注意： 如果上诉命令因为权限执行失败， 请使用 sudo 再次尝试运行
mv那行命令。
现在只需要运行 composer 命令就可以使用 Composer 而不需要输入 php composer.phar。
Composer 是 homebrew-php 项目的一部分。
brew updatebrew tap josegonzalez/homebrew-phpbrew tap homebrew/versionsbrew install php55-intlbrew install josegonzalez/php/composer这是将 Composer 安装在你机器上的最简单的方法。
下载并且运行 [Composer-Setup.exe][4]，它将安装最新版本的 Composer ，并设置好系统的环境变量，因此你可以在任何目录下直接使用 composer 命令。
设置系统的环境变量 PATH 并运行安装命令下载 composer.phar 文件：
C:Usersusername>cd C:binC:bin>php -r "readfile('https://getcomposer.org/installer');" | php注意： 如果收到 readfile 错误提示，请使用 http 链接或者在 php.ini 中开启 php_openssl.dll 。
在 composer.phar 同级目录下新建文件 composer.bat ：
C:bin>echo @php "%~dp0composer.phar" %*>composer.bat关闭当前的命令行窗口，打开新的命令行窗口进行测试：
C:Usersusername>composer -VComposer version 27d8904现在我们将使用 Composer 来安装项目的依赖。如果在当前目录下没有一个 composer.json 文件，请查看[基本用法][5]章节。
要解决和下载依赖，请执行 install 命令：
php composer.phar install如果你进行了全局安装，并且没有 phar 文件在当前目录，请使用下面的命令代替：
composer install继续 上面的例子，这里将下载 monolog 到 vendor/monolog/monolog 目录。
除了库的下载，Composer 还准备了一个自动加载文件，它可以加载 Composer 下载的库中所有的类文件。使用它，你只需要将下面这行代码添加到你项目的引导文件中：
require 'vendor/autoload.php';现在我们就可以使用 monolog 了！想要学习更多关于 Composer 的知识，请查看"基本用法"章节。
本章将告诉你如何通过 Composer 来安装你的库。
只要你有一个 composer.json 文件在目录中，那么整个目录就是一个包。当你添加一个 require 到项目中，你就是在创建一个依赖于其它库的包。你的项目和库之间唯一的区别是，你的项目是一个没有名字的包。
为了使它成为一个可安装的包，你需要给它一个名称。你可以通过 composer.json 中的 name 来定义：
{ "name": "acme/hello-world", "require": { "monolog/monolog": "1.0.*" }}在这种情况下项目的名称为 acme/hello-world，其中 acme 是供应商的名称。供应商的名称是必须填写的。
注意： 如果你不知道拿什么作为供应商的名称， 那么使用你 github 上的用户名通常是不错的选择。 虽然包名不区分大小写，但惯例是使用小写字母，并用连字符作为单词的分隔。
Composer 将那些已经安装在系统上，但并不是由 Composer 安装的包视为一个虚拟的平台软件包。这包括PHP本身，PHP扩展和一些系统库。
php 表示用户的 PHP 版本要求，你可以对其做出限制。例如 >=5.4.0。如果需要64位版本的 PHP，你可以使用 php-64bit 进行限制。
hhvm 代表的是 HHVM（也就是 HipHop Virtual Machine） 运行环境的版本，并且允许你设置一个版本限制，例如，'>=2.3.3'。
ext-<name> 可以帮你指定需要的 PHP 扩展（包括核心扩展）。通常 PHP 拓展的版本可以是不一致的，将它们的版本约束为 * 是一个不错的主意。一个 PHP 扩展包的例子：包名可以写成 ext-gd。
lib-<name> 允许对 PHP 库的版本进行限制。curl、iconv、icu、libxml、openssl、pcre、uuid、xsl。你可以使用 composer show --platform 命令来获取可用的平台软件包的列表。
你需要一些方法来指明自己开发的包的版本，当你在 Packagist 上发布自己的包，它能够从 VCS (git, svn, hg) 的信息推断出包的版本，因此你不必手动指明版本号，并且也不建议这样做。请查看 标签 和 分支 来了解版本号是如何被提取的。
如果你想要手动创建并且真的要明确指定它，你只需要添加一个 version 字段：
{ "version": "1.0.0"}注意： 你应该尽量避免手动设置版本号，因为标签的值必须与标签名相匹配。
对于每一个看起来像版本号的标签，都会相应的创建一个包的版本。它应该符合 'X.Y.Z' 或者 'vX.Y.Z' 的形式，-patch、-alpha、-beta 或 -RC 这些后缀是可选的。在后缀之后也可以再跟上一个数字。
下面是有效的标签名称的几个例子：
v2.0.4-p1
注意： 即使你的标签带有前缀 v， 由于在需要 require 一个版本的约束时是不允许这种前缀的， 因此 v 将被省略（例如标签 V1.0.0 将创建 1.0.0 版本）。
对于每一个分支，都会相应的创建一个包的开发版本。如果分支名看起来像一个版本号，那么将创建一个如同 {分支名}-dev 的包版本号。例如一个分支 2.0 将产生一个 2.0.x-dev 包版本（加入了 .x 是出于技术的原因，以确保它被识别为一个分支，而 2.0.x 的分支名称也是允许的，它同样会被转换为 2.0.x-dev）。如果分支名看起来不像一个版本号，它将会创建 dev-{分支名} 形式的版本号。例如 master 将产生一个 dev-master 的版本号。
下面是版本分支名称的一些示例：
1.1.x
注意： 当你安装一个新的版本时，将会自动从它 source 中拉取。 详细请查看 install 命令。
它表示一个包版本的别名。例如，你可以为 dev-master 设置别名 1.0.x-dev，这样就可以通过 require 1.0.x-dev 来得到 dev-master 版本的包。
详细请查看别名。
如果你愿意，可以在你的项目中提交 composer.lock 文件。他将帮助你的团队始终针对同一个依赖版本进行测试。任何时候，这个锁文件都只对于你的项目产生影响。
如果你不想提交锁文件，并且你正在使用 Git，那么请将它添加到 .gitignore 文件中。
一旦你有一个包含 composer.json 文件的库存储在线上版本控制系统（例如：Git），你的库就可以被 Composer 所安装。在这个例子中，我们将 acme/hello-world 库发布在 GitHub 上的 github.com/username/hello-world 中。
现在测试这个 acme/hello-world 包，我们在本地创建一个新的项目。我们将它命名为 acme/blog。此博客将依赖 acme/hello-world，而后者又依赖 monolog/monolog。我们可以在某处创建一个新的 blog 文件夹来完成它，并且需要包含 composer.json 文件：
{ "name": "acme/blog", "require": { "acme/hello-world": "dev-master" }}在这个例子中 name 不是必须的，因为我们并不想将它发布为一个库。在这里为 composer.json 文件添加描述。
现在我们需要告诉我们的应用，在哪里可以找到 hello-world 的依赖。为此我们需要在 composer.json 中添加 repositories 来源申明：
{ "name": "acme/blog", "repositories": [ { "type": "vcs", "url": "https://github.com/username/hello-world" } ], "require": { "acme/hello-world": "dev-master" }}更多关于包的来源是如何工作的，以及还有什么其他的类型可供选择，请查看资源库。
这就是全部了。你现在可以使用 Composer 的 install 命令来安装你的依赖包了！
小结： 任何含有 composer.json 的 GIT、SVN、HG 存储库，都可以通过 require 字段指定“包来源”和“声明依赖”来添加到你的项目中。
好的，你现在可以发布你的包了，但你不会希望你的用户每次都这样繁琐的指定包的来源。
你可能注意到了另一件事，我们并没有指定 monolog/monolog 的来源。它是怎么工作的？答案是 packagist。
Packagist 是 Composer 主要的一个包信息存储库，它默认是启用的。任何在 packagist 上发布的包都可以直接被 Composer 使用。就像 monolog 它被 发布在 packagist 上，我们可以直接使用它，而不必指定任何额外的来源信息。
如果我们想与世界分享我们的 hello-world，我们最好将它发布到 packagist 上。这样做是很容易的。
你只需要点击那个大大的 "Submit Package" 按钮并注册。接着提交你库的来源地址，此时 packagist 就开始了抓取。一旦完成，你的包将可以提供给任何人使用。
你已经学会了如何使用命令行界面做一些事情。本章将向你介绍所有可用的命令。
为了从命令行获得帮助信息，请运行 composer 或者 composer list 命令，然后结合 --help 命令来获得更多的帮助信息。
下列参数可与每一个命令结合使用：
在 库 那一章我们看到了如何手动创建 composer.json 文件。实际上还有一个 init 命令可以更容易的做到这一点。
当您运行该命令，它会以交互方式要求您填写一些信息，同时聪明的使用一些默认值。
php composer.phar initfoo/bar:1.0.0 这样的格式。minimum-stability 字段的值。install 命令从当前目录读取 composer.json 文件，处理了依赖关系，并把其安装到 vendor 目录下。
php composer.phar install如果当前目录下存在 composer.lock 文件，它会从此文件读取依赖版本，而不是根据 composer.json 文件去获取依赖。这确保了该库的每个使用者都能得到相同的依赖版本。
如果没有 composer.lock 文件，composer 将在处理完依赖关系后创建它。
source 和 dist。对于稳定版本 composer 将默认使用 dist 方式。而 source 表示版本控制源 。如果 --prefer-source 是被启用的，composer 将从 source 安装（如果有的话）。如果想要使用一个 bugfix 到你的项目，这是非常有用的。并且可以直接从本地的版本库直接获取依赖关系。--prefer-source 相反，composer 将尽可能的从 dist 获取，这将大幅度的加快在 build servers 上的安装。这也是一个回避 git 问题的途径，如果你不清楚如何正确的设置。--dry-run 命令，它将模拟安装并显示将会发生什么。require-dev 字段中列出的包（这是一个默认值）。require-dev 字段中列出的包。composer.json 文件中定义的脚本。为了获取依赖的最新版本，并且升级 composer.lock 文件，你应该使用 update 命令。
php composer.phar update这将解决项目的所有依赖，并将确切的版本号写入 composer.lock。
如果你只是想更新几个包，你可以像这样分别列出它们：
php composer.phar update vendor/package vendor/package2你还可以使用通配符进行批量更新：
php composer.phar update vendor/*source 安装。dist 安装。require-dev 字段中列出的包（这是一个默认值）。require-dev 字段中列出的包。composer.json 文件中定义的脚本。require 命令增加新的依赖包到当前目录的 composer.json 文件中。
php composer.phar require在添加或改变依赖时， 修改后的依赖关系将被安装或者更新。
如果你不希望通过交互来指定依赖包，你可以在这条令中直接指明依赖包。
php composer.phar require vendor/package:2.* vendor/package2:dev-mastersource 安装。dist 安装。require-dev 字段中列出的包。global 命令允许你在 COMPOSER_HOME 目录下执行其它命令，像 install、require 或 update。
并且如果你将 $COMPOSER_HOME/vendor/bin 加入到了 $PATH 环境变量中，你就可以用它在命令行中安装全局应用，下面是一个例子：
php composer.phar global require fabpot/php-cs-fixer:dev-master现在 php-cs-fixer 就可以在全局范围使用了（假设你已经设置了你的 PATH）。如果稍后你想更新它，你只需要运行 global update：
php composer.phar global updatesearch 命令允许你为当前项目搜索依赖包，通常它只搜索 packagist.org 上的包，你可以简单的输入你的搜索条件。
php composer.phar search monolog您也可以通过传递多个参数来进行多条件搜索。
列出所有可用的软件包，你可以使用 show 命令。
php composer.phar show如果你想看到一个包的详细信息，你可以输入一个包名称。
php composer.phar show monolog/monologname : monolog/monologversions : master-dev, 1.0.2, 1.0.1, 1.0.0, 1.0.0-RC1type : librarynames : monolog/monologsource : [git] http://github.com/Seldaek/monolog.git 3d4e60d0cbc4b888fe5ad223d77964428b1978dadist : [zip] http://github.com/Seldaek/monolog/zipball/3d4e60d0cbc4b888fe5ad223d77964428b1978da 3d4e60d0cbc4b888fe5ad223d77964428b1978dalicense : MITautoloadpsr-0Monolog : src/requiresphp >=5.3.0你甚至可以输入一个软件包的版本号，来显示该版本的详细信息。
php composer.phar show monolog/monolog 1.0.2depends 命令可以查出已安装在你项目中的某个包，是否正在被其它的包所依赖，并列出他们。
php composer.phar depends --link-type=require monolog/monolognrk/monolog-fluentpoc/pocpropel/propelsymfony/monolog-bridgesymfony/symfonyrequire 也可以是 require-dev。在提交 composer.json 文件，和创建 tag 前，你应该始终运行 validate 命令。它将检测你的 composer.json 文件是否是有效的
php composer.phar validate如果你经常修改依赖包里的代码，并且它们是从 source（自定义源）进行安装的，那么 status 命令允许你进行检查，如果你有任何本地的更改它将会给予提示。
php composer.phar status你可以使用 --verbose 系列参数（-v|vv|vvv）来获取更详细的详细：
php composer.phar status -vYou have changes in the following dependencies:vendor/seld/jsonlint: M README.mdown将 Composer 自身升级到最新版本，只需要运行 self-update 命令。它将替换你的 composer.phar 文件到最新版本。
php composer.phar self-update如果你想要升级到一个特定的版本，可以这样简单的指定它：
php composer.phar self-update 1.0.0-alpha7如果你已经为整个系统安装 Composer（参见 全局安装），你可能需要在 root 权限下运行它：
sudo composer self-updateconfigconfig 命令允许你编辑 Composer 的一些基本设置，无论是本地的 composer.json 或者全局的 config.json 文件。
php composer.phar config --listconfig [options] [setting-key] [setting-value1] ... [setting-valueN]
setting-key 是一个配置选项的名称，setting-value1 是一个配置的值。可以使用数组作为配置的值（像 github-protocols），多个 setting-value 是允许的。
有效的配置选项，请查看“架构”章节的 config 。
$COMPOSER_HOME/config.json 的全局配置文件。如果不指定该参数，此命令将影响当前项目的 composer.json 文件，或 --file 参数所指向的文件。--global 参数时，将会打开全局 composer.json 文件。setting-key 指定名称的配置选项。--global 参数时，将会显示全局配置选项的列表。--global 参数一起使用。除了修改配置选项， config 命令还支持通过以下方法修改来源信息：
php composer.phar config repositories.foo vcs http://github.com/foo/bar你可以使用 Composer 从现有的包中创建一个新的项目。这相当于执行了一个 git clone 或 svn checkout 命令后将这个包的依赖安装到它自己的 vendor 目录。
此命令有几个常见的用途：
要创建基于 Composer 的新项目，你可以使用 "create-project" 命令。传递一个包名，它会为你创建项目的目录。你也可以在第三个参数中指定版本号，否则将获取最新的版本。
如果该目录目前不存在，则会在安装过程中自动创建。
php composer.phar create-project doctrine/orm path 2.2.*此外，你也可以无需使用这个命令，而是通过现有的 composer.json 文件来启动这个项目。
默认情况下，这个命令会在 packagist.org 上查找你指定的包。
composer 资源库的 HTTP URL，或者是指向某个 packages.json 文件的本地路径。stable。source 安装。dist 安装。require-dev 字段中列出的包。某些情况下你需要更新 autoloader，例如在你的包中加入了一个新的类。你可以使用 dump-autoload 来完成，而不必执行 install 或 update 命令。
此外，它可以打印一个优化过的，符合 PSR-0/4 规范的类的索引，这也是出于对性能的可考虑。在大型的应用中会有许多类文件，而 autoloader 会占用每个请求的很大一部分时间，使用 classmaps 或许在开发时不太方便，但它在保证性能的前提下，仍然可以获得 PSR-0/4 规范带来的便利。
列出已安装的每个包的名称、版本、许可协议。可以使用 --format=json 参数来获取 JSON 格式的输出。
你可以运行此命令来手动执行 脚本，只需要指定脚本的名称，可选的 --no-dev 参数允许你禁用开发者模式。
如果你觉得发现了一个 bug 或是程序行为变得怪异，你可能需要运行 diagnose 命令，来帮助你检测一些常见的问题。
php composer.phar diagnose此命令用来对指定包的指定版本进行 zip/tar 归档。它也可以用来归档你的整个项目，不包括 excluded/ignored（排除/忽略）的文件。
php composer.phar archive vendor/package 2.0.21 --format=zip使用 help 可以获取指定命令的帮助信息。
php composer.phar help install你可以设置一些环境变量来覆盖默认的配置。建议尽可能的在 composer.json 的 config 字段中设置这些值，而不是通过命令行设置环境变量。值得注意的是环境变量中的值，将始终优先于 composer.json 中所指定的值。
环境变量 COMPOSER 可以为 composer.json 文件指定其它的文件名。
例如：
COMPOSER=composer-other.json php composer.phar install通过设置这个环境变量，你可以指定 root 包的版本，如果程序不能从 VCS 上猜测出版本号，并且未在 composer.json 文件中申明。
通过设置这个环境变量，你可以指定 composer 将依赖安装在 vendor 以外的其它目录中。
通过设置这个环境变量，你可以指定 bin（Vendor Binaries）目录到 vendor/bin 以外的其它目录。
如果你是通过 HTTP 代理来使用 Composer，你可以使用 http_proxy 或 HTTP_PROXY 环境变量。只要简单的将它设置为代理服务器的 URL。许多操作系统已经为你的服务设置了此变量。
建议使用 http_proxy（小写）或者两者都进行定义。因为某些工具，像 git 或 curl 将使用 http_proxy 小写的版本。另外，你还可以使用 git config --global http.proxy <proxy url> 来单独设置 git 的代理。
如果你是使用代理服务器，并且想要对某些域名禁用代理，就可以使用 no_proxy 环境变量。只需要输入一个逗号相隔的域名 排除 列表。
此环境变量接受域名、IP 以及 CIDR地址块。你可以将它限制到一个端口（例如：:80）。你还可以把它设置为 * 来忽略所有的 HTTP 代理请求。
如果你使用了 HTTP 代理，但它不支持 request_fulluri 标签，那么你应该设置这个环境变量为 false 或 0 ，来防止 composer 从 request_fulluri 读取配置。
如果你使用了 HTTPS 代理，但它不支持 request_fulluri 标签，那么你应该设置这个环境变量为 false 或 0 ，来防止 composer 从 request_fulluri 读取配置。
COMPOSER_HOME 环境变量允许你改变 Composer 的主目录。这是一个隐藏的、所有项目共享的全局目录（对本机的所有用户都可用）。
它在各个系统上的默认值分别为：
/home/<user>/.composer。/Users/<user>/.composer。C:Users<user>AppDataRoamingComposer。你可以在 COMPOSER_HOME 目录中放置一个 config.json 文件。在你执行 install 和 update 命令时，Composer 会将它与你项目中的 composer.json 文件进行合并。
若 全局 和 项目 存在相同配置项，那么项目中的 composer.json 文件拥有更高的优先级。
COMPOSER_CACHE_DIR 环境变量允许你设置 Composer 的缓存目录，这也可以通过 cache-dir 进行配置。
它在各个系统上的默认值分别为：
$COMPOSER_HOME/cache。C:Users<user>AppDataLocalComposer 或 %LOCALAPPDATA%/Composer。这个环境变量控制着 Composer 执行命令的等待时间（例如：git 命令）。默认值为300秒（5分钟）。
这个环境变量控制着 discard-changes config option。
如果设置为1，这个环境变量将使 Composer 在执行每一个命令时都放弃交互，相当于对所有命令都使用了 --no-interaction。可以在搭建 虚拟机/持续集成服务器 时这样设置。
本章将解释包和库的概念，什么样的存储库是可用的，以及它们如何工作。
在此之前，我们看到存在不同类型的资源库，我们需要了解一些基本概念，以理解 Composer 是如何构建于其上的。
Composer 是一个依赖管理工具。它在本地安装一些资源包。一个包本质上就是一个包含东西的目录。通常情况下它存储 PHP 代码，但在理论上它可以是任何东西。并且它包含一个描述，其中有一个名称和一个版本号，这个名称和版本号用于识别该包。
事实上，在 composer 内部将每一个版本都视为一个单独的包。尽管在你使用 composer 时这种区别无关紧要，但当你想改变它时，这就显得至关重要。
除了名称和版本号，还存放了有用的元数据。与安装关系最密切的是 source 信息，它申明了在哪里可以获得资源包的内容。包数据指向包内容，并有两种指向方式：dist 和 source。
Dist: dist 指向一个存档，该存档是对一个资源包的某个版本的数据进行的打包。通常是已经发行的稳定版本。
Source: source 指向一个开发中的源。这通常是一个源代码仓库，例如 git。当你想要对下载下来的资源包进行修改时，可以这样获取。
你可以使用其中任意一个，或者同时使用。这取决于其它的一些因素，比如“user-supplied 选项”和“包的稳定性”，前者将会被优先考虑。
一个资源库是一个包的来源。它是一个 packages/versions 的列表。Composer 将查看所有你定义的 repositories 以找到你项目需要的资源包。
默认情况下已经将 Packagist.org 注册到 Composer。你可以在 composer.json 中申明更多的资源库，把它们加入你的项目中。
资源库的定义仅可用于“root 包”，而在你依赖的包中定义的资源库将不会被加载。如果你想了解其中的原因，请阅读 FAQ entry。
主资源库的类型为 composer。它使用一个单一的 packages.json 文件，包含了所有的资源包元数据。
这也是 packagist.org 所使用的资源类型。要引用一个 composer 资源库，只需要提供一个存放 packages.json 文件的 目录路径。比如要引用 packagist.org 下的 /packages.json，它的 URL 就应该是 packagist.org。而 example.org/packages.json 的 URL 应该是 example.org。
唯一必须的字段是 packages。它的 JSON 结构如下：
{ "packages": { "vendor/package-name": { "dev-master": { @composer.json }, "1.0.x-dev": { @composer.json }, "0.0.1": { @composer.json }, "1.0.0": { @composer.json } } }}@composer.json 标记将会从此包的指定版本中读取 composer.json 的内容，其内至少应包含以下信息：
这是一个最简单的包定义：
{ "name": "smarty/smarty", "version": "3.1.7", "dist": { "url": "http://www.smarty.net/files/Smarty-3.1.7.zip", "type": "zip" }}它还可以包含任何在 composer.json 架构 中介绍的字段。
notify-batch 字段允许你指定一个 URL，它将会在用户安装每一个包时被调用。该 URL 可以是（与其资源库相同域名的）绝对路径或者一个完整的 URL 地址。
例如使用下面的值：
{ "notify-batch": "/downloads/"}对于 example.org/packages.json 包含的 monolog/monolog 包，它将会发送一个 POST 请求到 example.org/downloads/，使用下面的 JSON request body：
{ "downloads": [ {"name": "monolog/monolog", "version": "1.2.1.0"}, ]}version 字段将包含标准化的版本号。
notify-batch 字段是可选的。
对于较大的资源库，可以拆分 packages.json 为多个文件。includes 字段允许你引用这些额外的文件。
实例：
{ "includes": { "packages-2011.json": { "sha1": "525a85fb37edd1ad71040d429928c2c0edec9d17" }, "packages-2012-01.json": { "sha1": "897cde726f8a3918faf27c803b336da223d400dd" }, "packages-2012-02.json": { "sha1": "26f911ad717da26bbcac3f8f435280d13917efa5" } }}文件的 SHA-1 码允许它被缓存，仅在 hash 值改变时重新请求。
此字段是可选的。你也许并不需要它来自定义存储库。
的对于非常大的资源库，像 packagist.org 使用 so-called provider 文件是首选方法。provider-includes 字段允许你设置一个列表，来申明这个资源库提供的包名称。在这种情况下文件的哈希算法必须使用 sha256。
providers-url 描述了如何在服务器上找到这些 provider 文件。它是以资源库的根目录为起点的绝对路径。
实例：
{ "provider-includes": { "providers-a.json": { "sha256": "f5b4bc0b354108ef08614e569c1ed01a2782e67641744864a74e788982886f4c" }, "providers-b.json": { "sha256": "b38372163fac0573053536f5b8ef11b86f804ea8b016d239e706191203f6efac" } }, "providers-url": "/p/%package%$%hash%.json"}这些文件包含资源包的名称以及哈希值，以验证文件的完整性，例如：
{ "providers": { "acme/foo": { "sha256": "38968de1305c2e17f4de33aea164515bc787c42c7e2d6e25948539a14268bb82" }, "acme/bar": { "sha256": "4dd24c930bd6e1103251306d6336ac813b563a220d9ca14f4743c032fb047233" } }}上述文件申明了 acme/foo 和 acme/bar 可以在这个资源库找到，通过加载由 providers-url 引用的文件，替换 %package% 为包名并且替换 %hash% 为 sha256 的值。这些文件本身只包含上文提到的 packages 的定义。
这些字段是可选的。你也许并不需要它们来自定义存储库。
packages.json 文件是用一个 PHP 流加载的。你可以使用 options 参数来设定额外的流信息。你可以设置任何有效的PHP 流上下文选项。更多相关信息请查看 Context options and parameters。
VCS 表示版本控制系统。这包括像 git、svn 或 hg 这样的版本管理系统。Composer 有一个资源类型可以从这些系统安装软件包。
这里有几个用例。最常见的是维护自己 fork 的第三方库。如果你在项目中使用某些库，并且你决定改变这些库内的某些东西，你会希望你项目中使用的是你自己的修正版本。如果这个库是在 GitHub 上（这种情况经常出现），你可以简单的 fork 它并 push 你的变更到这个 fork 里。在这之后你更新项目的 composer.json 文件，添加你的 fork 作为一个资源库，变更版本约束来指向你的自定义分支。关于版本约束的命名约定请查看 库（资源包）。
例如，假设你 fork 了 monolog，在 bugfix 分支修复了一个 bug：
{ "repositories": [ { "type": "vcs", "url": "https://github.com/igorw/monolog" } ], "require": { "monolog/monolog": "dev-bugfix" }}当你运行 php composer.phar update 时，你应该得到你修改的版本，而不是 packagist.org 上的 monolog/monolog。
注意，你不应该对包进行重命名，除非你真的打算摆脱原来的包，并长期的使用你自己的 fork。这样 Composer 就会正确获取你的包了。如果你确定要重命名这个包，你应该在默认分支（通常是 master 分支）上操作，而不是特性分支，因为包的名字取自默认分支。
如果其它包依赖你 fork 的这个分支，可能要对它做版本号的行内别名设置，才能够准确的识别版本约束。更多相关信息请查看 别名。
完全相同的解决方案，也可以让你使用你 GitHub 和 BitBucket 上的私人代码库进行工作：
{ "require": { "vendor/my-private-repo": "dev-master" }, "repositories": [ { "type": "vcs", "url": "git@bitbucket.org:vendor/my-private-repo.git" } ]}唯一的要求是为一个 git 客户端安装 SSH 秘钥。
Git 并不是 VCS 资源库唯一支持的版本管理系统。
以下几种都是被支持的：
为了从这些系统获取资源包，你必须安装对应的客户端，这可能是不方便的。基于这个原因，这里提供了 GitHub 和 BitBucket 的 API 的特殊支持，以便在无需安装版本控制系统的情况下获取资源包。在 VCS 资源库提供的 dist 中获取 zip 存档。
VCS 驱动将基于 URL 自动检测版本库类型。但如果可能，你需要明确的指定一个 git、svn 或 hg 作为资源库类型，而不是 vcs。
If you set the no-api key to true on a github repository it will clone the repository as it would with any other git repository instead of using the GitHub API. But unlike using the git driver directly, composer will still attempt to use github's zip files.
由于 Subversion 没有原生的分支和标签的概念，Composer 假设在默认情况下该代码位于 $url/trunk、$url/branches 和 $url/tags 内。如果你的存储库使用了不同的布局，你可以更改这些值。例如，如果你使用大写的名称，你可以像这样配置资源库：
{ "repositories": [ { "type": "vcs", "url": "http://svn.example.org/projectA/", "trunk-path": "Trunk", "branches-path": "Branches", "tags-path": "Tags" } ]}如果你的存储库目录中没有任何分支或标签文件夹，你可以将 branches-path 或 tags-path 设置为 false。
如果是一个位于子目录的包，例如， /trunk/foo/bar/composer.json 和 /tags/1.0/foo/bar/composer.json，那么你可以让 composer 通过 "package-path" 选项设置的子目录进行访问，在这个例子中可以将其设置为 "package-path": "foo/bar/"。
pear 类型资源库，使得从任何 PEAR 渠道安装资源包成为可能。Composer 将为所有此类型的包增加前缀（类似于 pear-{渠道名称}/）以避免冲突。而在之后使用别名时也增加前缀（如 pear-{渠道别名}/）。
例如使用 pear2.php.net：
{ "repositories": [ { "type": "pear", "url": "http://pear2.php.net" } ], "require": { "pear-pear2.php.net/PEAR2_Text_Markdown": "*", "pear-pear2/PEAR2_HTTP_Request": "*" }}在这种情况下渠道的简称（别名）是 pear2，因此 PEAR2_HTTP_Request 包的名称应该写作 pear-pear2/PEAR2_HTTP_Request。
注意：
pear类型的资源库对每个 requires 都要做完整的请求，因此可能大大降低安装速度。
通过自定义供应商名称，对 PEAR 渠道包进行别名是允许的。
例：
假设你有一个私人 PEAR 库，并希望使用 Composer 从 VCS 集成依赖。你的 PEAR 库包含以下资源包：
BasePackage。IntermediatePackage 依赖于 BasePackage。TopLevelPackage1 和 TopLevelPackage2 都依赖于 IntermediatePackage。如果没有一个供应商别名，Composer 将使用 PEAR 渠道名称作为包名的一部分：
pear-pear.foobar.repo/BasePackagepear-pear.foobar.repo/IntermediatePackagepear-pear.foobar.repo/TopLevelPackage1pear-pear.foobar.repo/TopLevelPackage2假设之后的某个时间，你希望将你的 PEAR 包迁移，使用 Composer 资源库和命名方案，并且采用 foobar 作为供应商名称。这样之前使用 PEAR 包的项目将不会看到更新的资源包，因为它们有不同的供应商名称（foobar/IntermediatePackage 与 pear-pear.foobar.repo/IntermediatePackage）。
你可以通过从一开始就为 PEAR 资源库指定 vendor-alias 来避免这种情况的发生，以得到一个不会过时的包名。
为了说明这一点，下面的例子会从你的 PEAR 资源库中得到 BasePackage、TopLevelPackage1 和 TopLevelPackage2 资源包，并从 Github 资源库中获取 IntermediatePackage 资源包：
{ "repositories": [ { "type": "git", "url": "https://github.com/foobar/intermediate.git" }, { "type": "pear", "url": "http://pear.foobar.repo", "vendor-alias": "foobar" } ], "require": { "foobar/TopLevelPackage1": "*", "foobar/TopLevelPackage2": "*" }}如果你想使用一个项目，它无法通过上述任何一种方式支持 composer，你仍然可以使用 package 类型定义资源库。
基本上，你可以定义与 packages.json 中 composer 类型资源库相同的信息，但需要为每个这样的资源包分别定义。同样，至少应该包含以下信息：name、version、（dist 或 source）。
这是一个 smarty 模板引擎的例子：
{ "repositories": [ { "type": "package", "package": { "name": "smarty/smarty", "version": "3.1.7", "dist": { "url": "http://www.smarty.net/files/Smarty-3.1.7.zip", "type": "zip" }, "source": { "url": "http://smarty-php.googlecode.com/svn/", "type": "svn", "reference": "tags/Smarty_3_1_7/distribution/" }, "autoload": { "classmap": ["libs/"] } } } ], "require": { "smarty/smarty": "3.1.*" }}通常你不需要去定义 source，因为你并不是真的需要它。
注意： 该资源库类型存在以下限制，因此应尽可能避免使用：
- Composer 将不会更新资源包，除非你修改了
version字段。- Composer 将不会更新 commit references，因此如果你使用
masterreference，将不得不删除该程序包以强制更新，并且将不得不面对一个不稳定的 lock 文件。
尽管大部分的时间，你大概都会把资源包放在 packagist.org 上，但这里还将告诉你一些用例，以便你可以自行托管资源库。
Private company packages: 如果你是一个公司的职员，对公司内部的资源包使用 composer，你可能会想让这些包保持私有的状态。
对于自行托管的软件包，建议使用 composer 类型资源库设置，它将提供最佳的性能。
这里有一些工具，可以帮助你创建 composer 类型的资源库。
packagist 的底层是开源的。这意味着你可以只安装你自己拷贝的 packagist，改造并使用它。这真的是很直接简单的事情。然而，由于其规模和复杂性，对于大多数中小型企业还是建议使用 Satis。
Packagist 是一个 Symfony2 应用程序，并且托管在 GitHub 上 github.com/composer/packagist。它内部使用了 composer 并作为 VCS 资源库与 composer 用户之间的代理。它拥有所有 VCS 资源包的列表，定期重新抓取它们，并将其作为一个 composer 资源库。
要设置你的副本，只需要按照 github.com/composer/packagist 的说明进行操作。
Satis 是一个静态的 composer 资源库生成器。它像是一个超轻量级的、基于静态文件的 packagist 版本。
你给它一个包含 composer.json 的存储库，定义好 VCS 和 资源库。它会获取所有你列出的包，并打印 packages.json 文件，作为 composer 类型的资源库。
更多详细信息请查看 github.com/composer/satis 和 Satis article。
在某些情况下，或许没有能力拥有之前提到的任何一种线上资源库。Typical example could be cross-organisation library exchange through built artifacts。当然大部分的时间他们都是私有的。为了简化维护，可以简单的使用 artifact 资源库类型，来引用一个包含那些私有包的 ZIP 存档的文件夹：
{ "repositories": [ { "type": "artifact", "url": "path/to/directory/with/zips/" } ], "require": { "private-vendor-one/core": "15.6.2", "private-vendor-two/connectivity": "*", "acme-corp/parser": "10.3.5" }}每个 zip artifact 都只是一个 ZIP 存档，放置在 composer.json 所在的根目录：
unzip -l acme-corp-parser-10.3.5.zipcomposer.json...如果有两个不同版本的资源包，它们都会被导入。当有一个新版本的存档被添加到 artifact 文件夹，并且你运行了 update 命令，该版本就会被导入，并且 Composer 将更新到最新版本。
你可以在 composer.json 中禁用默认的 Packagist 资源库。
{ "repositories": [ { "packagist": false } ]}当你使用 VCS 资源库，你将只会得到类似于这样的版本号：从分支发布的标签获取，它看起来像 2.0 或 2.0.x。比较特殊的是，对于你的 master 分支，你会得到一个最新提交的 dev-master 版本。对于你的 bugfix 分支，你会得到一个最新提交的 dev-bugfix 版本。以此类推，这些特殊的版本标识可以用来获取最新的分支源码。
如果你的 master 分支使用标签发布了 1.0 系列版本，即 1.0.1、1.0.2、1.0.3 等等，任何依赖它的资源包都可能会使用 1.0.* 这个版本约束。
如果有人想要最新的 dev-master 版本，他们将会碰到一个问题：另一些依赖它的包可能使用了 1.0.* 这个版本约束，因此在 require 这个开发版本时将会产生冲突，因为 dev-master 不符合 1.0.* 的约束。
这时，就可以使用别名。
dev-master 指向一个在你 VCS 项目上的主分支。有些用户会想要使用最新的开发版本，这是相当常见的情况。因此，Composer 允许你别名你的 dev-master 版本为一个 1.0.x-dev 的版本号。这是通过在 composer.json 文件中的 extra 下指定 branch-alias 字段来完成的：
{ "extra": { "branch-alias": { "dev-master": "1.0.x-dev" } }}此处的分支版本必须以 dev- 开头（不可比较的版本名称），对应的别名必须是可比较的开发版本名称（即，以数字开头，并以 .x-dev 结束）。branch-alias 所引用的分支必须是存在的。对于 dev-master 你需要在 master 分支上提交它。
其结果是，任何人都可以使用 1.0.* 版本约束来得到 dev-master 版本。
为了定义分支别名，你必须是需要别名的包的所有者。如果你想别名一个第三方包，而又不想 fork 它到自己的版本库，可以使用行内别名，我们在接下来就会提到它。
分支别名是非常适合用于主开发分支的。但为了使用它们，你需要拥有对源码的控制权，并且你需要提交别名修改到你控制的版本库。
当你只想在本地项目中尝试一些依赖包的 bug 修正时，这并不是最好的方式。
出于这个原因，你可以在 require 和 require-dev 字段中直接别名你需要的包。比方说那你找到了 monolog/monolog 的一个 bug。你在 GitHub 上克隆了 Monolog 并在名为 bugfix 的分支上修正了一个问题。现在你想安装这个版本到你的本地项目。
你所使用的 symfony/monolog-bundle require 了 monolog/monolog 并约束了版本 1.*. 因此你需要让你的 dev-bugfix 满足该版本约束。
只要在你项目根目录的 composer.json 文件中加入以下内容：
{ "repositories": [ { "type": "vcs", "url": "https://github.com/you/monolog" } ], "require": { "symfony/monolog-bundle": "2.0", "monolog/monolog": "dev-bugfix as 1.0.x-dev" }}它将会在你的 GitHub 上获取 monolog/monolog 的 dev-bugfix 版本并将其版本别名为 1.0.x-dev。
注意： 如果要对一个资源包使用行内别名，这个别名（
as的右边）必须能够使用版本约束。as左边的部分在这之后将被丢弃。因此，如果 A 依赖 B 而 B 又依赖monolog/monolog且版本约束为dev-bugfix as 1.0.x-dev，那么安装 A 时将使用 B 的版本约束，并识别为1.0.x-dev，此时必须真实存在一个“分支别名”或“1.0 系列分支”。否则就必须在 A 的composer.json文件中再次定义行内别名。注意： 应该尽量避免行内别名，特别是对已经发布的包。如果你发现了一个 bug，请尝试将你的修复合并到上游分支。这将避免使用你资源包的用户出现问题。
有时需要在包的安装过程中执行其它的动作，例如：将它安装在默认的 vendor 以外的其它目录。
在这些情况下，你可以考虑创建一个自定义安装程序来处理特定的逻辑。
假设你的项目已经有了一个自定义的安装模块，那么如何根据 安装类型 正确调用你包文件中的安装程序就成为了一个问题。
参见见下一章，如何通过指令创建自定义安装程序。
任何自定义安装程序都要通过 type 属性来识别。一旦被确认，它将完全覆盖默认的安装程序，并执行自己的安装逻辑。
一个实际用例：
phpDocumentor 的特殊模板需要安装在 /vendor 以外的其它目录中。 因此他们选择 phpdocumentor-template 安装类型 并为此类型创建了一个插件，以便将他们的模板发送到正确的目录中。
在这样一个模板包的例子中 composer.json 将使用以下设置：
{ "name": "phpdocumentor/template-responsive", "type": "phpdocumentor-template", "require": { "phpdocumentor/template-installer-plugin": "*" }}重要提示： 为了确保这个模板安装程序在安装模板包之前就已存在，模板包必须写入对此安装程序包的依赖。
一个自定义安装程序通常是以 Composer 插件的形式存在，并包含有一个类，它实现了 ComposerInstallerInstallerInterface 这个接口。
一个基本的安装程序插件必须由3个文件组成：
MyProjectComposerPlugin.php，其中的类必须实现 ComposerPluginPluginInterface 接口。MyProjectComposerInstaller.php，其中的类必须实现 ComposerInstallerInstallerInterface 接口。此处的包文件和普通资源包是相同的，但需要满足以下条件：
实例：
{ "name": "phpdocumentor/template-installer-plugin", "type": "composer-plugin", "license": "MIT", "autoload": { "psr-0": {"phpDocumentorComposer": "src/"} }, "extra": { "class": "phpDocumentorComposerTemplateInstallerPlugin" }, "require": { "composer-plugin-api": "1.0.0" }}这个类定义了 Composer 的插件，它必须实现 ComposerPluginPluginInterface 这个接口。它可以在 activate() 方法中注册自定义安装程序。
这个类可以被放在任何位置、使用任何名字，只要能够根据 extra.class 中的定义被自动加载即可。
实例：
<?phpnamespace phpDocumentorComposer;use ComposerComposer;use ComposerIOIOInterface;use ComposerPluginPluginInterface;class TemplateInstallerPlugin implements PluginInterface{ public function activate(Composer $composer, IOInterface $io) { $installer = new TemplateInstaller($io, $composer); $composer->getInstallationManager()->addInstaller($installer); }}这个类用于执行自定义的安装过程，它必须实现 ComposerInstallerInstallerInterface 这个接口（或者继承了另一个实现此接口的安装程序类）。它将会对安装类型中定义的字符串执行 supports() 方法验证，一旦通过就采用对应的安装程序。
注意： 请慎重选择你的 安装类型 名称，建议遵循这样的格式：vendor-type。例如：phpdocumentor-template。
InstallerInterface 类定义了以下方法（请查阅源码以获得更详细的信息）：
实例：
<?phpnamespace phpDocumentorComposer;use ComposerPackagePackageInterface;use ComposerInstallerLibraryInstaller;class TemplateInstaller extends LibraryInstaller{ /** * {@inheritDoc} */ public function getPackageBasePath(PackageInterface $package) { $prefix = substr($package->getPrettyName(), 0, 23); if ('phpdocumentor/template-' !== $prefix) { throw new InvalidArgumentException( 'Unable to install template, phpdocumentor templates ' .'should always start their package name with ' .'"phpdocumentor/template-"' ); } return 'data/templates/'.substr($package->getPrettyName(), 23); } /** * {@inheritDoc} */ public function supports($packageType) { return 'phpdocumentor-template' === $packageType; }}这个例子演示了，简单的继承 ComposerInstallerLibraryInstaller 类来剥离 phpdocumentor/template- 前缀，并用剩余的部分重新组装了一个完全不同的安装路径。
并非安装在 /vendor 目录，任何使用这个安装程序的资源包，将被放置在 /data/templates/<stripped name> 目录中。
你可能需要改变和扩展 Composer 加入自定义的功能。例如：如果你的环境对 Composer 的行为有特殊要求，而这并不适用于普通用户。又或者，你想使用 Composer 完成某些事情，而又不希望对普通用户造成影响。
在这些情况下，你可以考虑创建一个插件来处理特定的逻辑。
一个插件就是一个普通的 Composer 资源包，插件的主要代码都位于这个包中，并且还可以依赖更多其它的资源包。
插件包内的文件和普通资源包相同，但必须满足下列要求：
此外，你必须 require 一个特殊的资源包 composer-plugin-api，定义与你的插件相兼容的 composer plugin API 版本。目前 composer plugin API 的版本为1.0.0。
实例：
{ "name": "my/plugin-package", "type": "composer-plugin", "require": { "composer-plugin-api": "1.0.0" }}每一个插件都必须提供一个实现了 ComposerPluginPluginInterface 接口的类。类中的 activate() 方法在插件载入后被调用，并接收两个类的实例：ComposerComposer 和 ComposerIOIOInterface。使用这两个对象可以读取所有的配置，操作所有的内部对象和状态。
实例：
<?phpnamespace phpDocumentorComposer;use ComposerComposer;use ComposerIOIOInterface;use ComposerPluginPluginInterface;class TemplateInstallerPlugin implements PluginInterface{ public function activate(Composer $composer, IOInterface $io) { $installer = new TemplateInstaller($io, $composer); $composer->getInstallationManager()->addInstaller($installer); }}此外，插件还可以实现 ComposerEventDispatcherEventSubscriberInterface 接口，为了在插件载入后自动注册事件处理程序到 EventDispatcher。
插件可用事件如下：
PRE_FILE_DOWNLOAD 在文件下载前被触发，它允许你在下载前根据目标 URL 操作 RemoteFilesystem 对象。
一个插件也可以订阅 脚本事件。
实例：
<?phpnamespace NadermanComposerAWS;use ComposerComposer;use ComposerEventDispatcherEventSubscriberInterface;use ComposerIOIOInterface;use ComposerPluginPluginInterface;use ComposerPluginPluginEvents;use ComposerPluginPreFileDownloadEvent;class AwsPlugin implements PluginInterface, EventSubscriberInterface{ protected $composer; protected $io; public function activate(Composer $composer, IOInterface $io) { $this->composer = $composer; $this->io = $io; } public static function getSubscribedEvents() { return array( PluginEvents::PRE_FILE_DOWNLOAD => array( array('onPreFileDownload', 0) ), ); } public function onPreFileDownload(PreFileDownloadEvent $event) { $protocol = parse_url($event->getProcessedUrl(), PHP_URL_SCHEME); if ($protocol === 's3') { $awsClient = new AwsClient($this->io, $this->composer->getConfig()); $s3RemoteFilesystem = new S3RemoteFilesystem($this->io, $event->getRemoteFilesystem()->getOptions(), $awsClient); $event->setRemoteFilesystem($s3RemoteFilesystem); } }}插件包是优先被安装和加载的，在 Composer 启动时，如果在已安装资源包的当前项目列表中被找到，它们将被自动加载。此外，所有的插件包将被安装在 COMPOSER_HOME 目录，以便在 Composer 全局命令前载入，在操作本地项目前插件就已经被载入。
你可以通过 --no-plugins 选项让 composer 的命令禁用所有已经安装的插件。这或许是特别有用的，如果任何插件会导致错误，而你想要升级或卸载它。
一个脚本，在 Composer 中，可以是一个 PHP 回调（定义为静态方法）或任何命令行可执行的命令。脚本对于在 Composer 运行过程中，执行一个资源包的自定义代码或包专用命令是非常有用的。
注意：只有在根包的 composer.json 中定义的脚本才会被执行。即便根包的外部依赖定义了其自身的脚本，Composer 也不会去执行这些额外的脚本。
Composer 在运行过程中将会触发以下事件：
| 事件名称 | 详细说明 |
|---|---|
| **pre-install-cmd** | 在 `install` 命令执行前触发。 |
| **post-install-cmd** | 在 `install` 命令执行后触发。 |
| **pre-update-cmd** | 在 `update` 命令执行前触发。 |
| **post-update-cmd** | 在 `update` 命令执行后触发。 |
| **pre-status-cmd** | 在 `status` 命令执行前触发。 |
| **post-status-cmd** | 在 `status` 命令执行后触发。 |
| **pre-package-install** | 在资源包安装前触发。 |
| **post-package-install** | 在资源包安装后触发。 |
| **pre-package-update** | 在资源包更新前触发。 |
| **post-package-update** | 在资源包更新后触发。 |
| **pre-package-uninstall** | 在资源包被卸载前触发。 |
| **post-package-uninstall** | 在资源包被卸载后触发。 |
| **pre-autoload-dump** | 在自动加载器被转储前触发，无论是 `install`/`update` 还是 `dump-autoload` 命令都会触发。 |
| **post-autoload-dump** | 在自动加载器被转储后触发，无论是 `install`/`update` 还是 `dump-autoload` 命令都会触发。 |
| **post-root-package-install** | 在 `create-project` 命令期间，根包安装完成后触发。 |
| **post-create-project-cmd** | 在 `create-project` 命令执行后触发。 |
archive command is executed.post-archive-cmd: occurs after the archive command is executed.
注意：Composer 不会去执行任何依赖包中定义的 install 或 update 相关脚本。因此你不应该在依赖包中申明 pre-update-cmd 或 pre-install-cmd。如果你需要在执行 install 或 update 命令前使用脚本，请确保它们已被定义在根包中。
在 composer.json 的根 JSON 对象中应该有一个名为 "scripts" 的属性，它包含有一系列的事件名称，以及对应的事件脚本。一个事件的脚本可以被定义为一个字符串（仅适用于单个脚本）或数组（单个或多个脚本）。
对于任何给定的事件：
脚本定义实例：
{ "scripts": { "post-update-cmd": "MyVendorMyClass::postUpdate", "post-package-install": [ "MyVendorMyClass::postPackageInstall" ], "post-install-cmd": [ "MyVendorMyClass::warmCache", "phpunit -c app/" ] }}使用前面定义的例子，这里的 MyVendorMyClass 类，就可以被使用来执行 PHP 的回调：
<?phpnamespace MyVendor;use ComposerScriptEvent;class MyClass{ public static function postUpdate(Event $event) { $composer = $event->getComposer(); // do stuff } public static function postPackageInstall(Event $event) { $installedPackage = $event->getOperation()->getPackage(); // do stuff } public static function warmCache(Event $event) { // make cache toasty }}当一个事件被触发，Composer 的内部事件处理程序将接收一个 ComposerScriptEvent 对象，这是传递给您的 PHP 回调的第一个参数。这个 Event 对象拥有一些 getter 方法来帮助你取得当前事件的上下文：
getComposer(): 返回当前的 ComposerComposer 对象实例。getName(): 返回事件名称的字符串。getIO(): 返回当前的 输入输出 流，它实现了 ComposerIOIOInterface 接口，以便在控制台中使用。如果你想手动运行事件脚本，可以使用下面的语法结构：
composer run-script [--dev] [--no-dev] script例如 composer run-script post-install-cmd 将会运行所有 post-install-cmd 事件下定义的脚本。
vendor/bin 目录一个 Composer 资源包，想要传递给安装它的用户的任何命令行脚本， 都应该被列入 二进制供应库。
如果一个资源包，含有不被用户所需要的其他脚本（比如构建或编译脚本） 那么这些代码不应该被列入二进制供应库。
它是通过在项目的 composer.json 里添加一个 bin 键定义的。 它是以一种文件的数组的形式定义的，这样任何给定的项目 都可以添加多个二进制文件。
{ "bin": ["bin/my-script", "bin/my-other-script"]}对于任何 依赖于 该资源包的项目， 它将引导 Composer 安装资源包里的二进制文件到 vendor/bin 目录。
这是一个便捷的途径来暴露有用的脚本， 否则它们将会被隐藏在 vendor/ 目录的深处。
对于被某个资源包直接定义的二进制供应库，什么也不会发生。
Composer 会检查所有依赖包里定义的二进制文件。 并为每一个依赖的二进制库设立一个指向 vendor/bin 的软连接。
比如 my-vendor/project-a 资源包的二进制库就是这样安装的：
{ "name": "my-vendor/project-a", "bin": ["bin/project-a-bin"]}在该 composer.json 上执行 composer install 命令， 不会对 bin/project-a-bin 造成任何影响。
再比如项目 my-vendor/project-b 有这样的 require 定义：
{ "name": "my-vendor/project-b", "require": { "my-vendor/project-a": "*" }}在该 composer.json 上执行 composer install 命令时， 将会检查 project-b 的所有依赖包，并安装它们的二进制库到 vendor/bin 目录。
这种情况下，Composer 将使 vendor/bin/project-a-bin 可以作为 vendor/my-vendor/project-a/bin/project-a-bin 的访问路径。在类 Unix 平台上， 这是通过创建软链接实现的。
完全由 Composer 管理的包并不 需要 包含任何用以兼容 Windows 的 .bat 文件。在 Windows 环境下运行时，Composer 会用一种特殊的方式处理 二进制文件的安装：
.bat 文件会自动生成有时资源包需要维护自定义的 .bat 文件来支持工作流，它可以不包含在 Composer 中。 这种情况下，该资源包 不 应该把它们作为二进制文件列出，因为 Composer 不需要知道它们。
当然，这里有两种指定二进制供应库的其他可选位置的方法：
composer.json 文件中的 bin-dir 配置属性处设置COMPOSER_BIN_DIR前者的实例如下：
{ "config": { "bin-dir": "scripts" }}在这个 composer.json 上运行 composer install 会把所有的二进制供应库 都安装在 scripts/ 目录，而不是缺省的 vendor/bin/ 目录。
对于现代语言而言，包管理器基本上是标配。Java有Maven，Python有pip，Ruby有gem，Nodejs有npm。PHP的则是PEAR，不过PEAR坑不少：
好在我们有Composer，PHP依赖管理的利器。它是开源的，使用起来也很简单，提交自己的包也很容易。
Composer需要PHP 5.3.2+才能运行。
$ curl -sS https://getcomposer.org/installer | php这个命令会将composer.phar下载到当前目录。PHAR（PHP 压缩包）是一个压缩格式，可以在命令行下直接运行。
你可以使用--install-dir选项将Composer安装到指定的目录，例如：
$ curl -sS https://getcomposer.org/installer | php -- --install-dir=bin当然也可以进行全局安装：
$ curl -sS https://getcomposer.org/installer | php$ mv composer.phar /usr/local/bin/composer在Mac OS X下也可以使用homebrew安装：
brew tap josegonzalez/homebrew-php brew install josegonzalez/php/composer 不过通常情况下只需将composer.phar的位置加入到PATH环境变量就可以，不一定要全局安装。
在项目目录下创建一个composer.json文件，指明依赖，比如，你的项目依赖 monolog：
{ "require": { "monolog/monolog": "1.2.*" }}安装依赖非常简单，只需在项目目录下运行：
composer install 如果没有全局安装的话，则运行：
php composer.phar install Composer提供了自动加载的特性，只需在你的代码的初始化部分中加入下面一行：
require 'vendor/autoload.php'; packagist.org是Composer的仓库，很多著名的PHP库都能在其中找到。你也可以提交你自己的作品。
以上介绍了Composer 的基本用法。Composer还有一些高级特性，虽然不是必需的，但是往往能给PHP开发带来方便。
每个框架都可能有一个或多个不同的依赖包安装目录。Composer 可以通过使用 composer/installers 来配置，安装依赖到其它的目录，而不是默认的 vendor 目录。
如果你是一个 包作者 并且希望自己的资源包被安装到自定义的目录中，简单的 require composer/installers 依赖，并设置适当的 type 属性。这是常见的方式，如果你的资源包专门用于一个框架，如 CakePHP、Drupal 或 WordPress。这是一个 WordPress 主题的 composer.json 文件的例子：
{ "name": "you/themename", "type": "wordpress-theme", "require": { "composer/installers": "~1.0" }}现在当你用 Composer 安装这个主题时，它就会被放置在 wp-content/themes/themename/ 目录。目前已被支持的 type 类型请查看 current supported types。
对于一个 包使用者 你可以为一个包设置或覆盖安装路径，requires composer/installers 并在 extra 下设置 installer-paths 属性。Drupal 的多站点设置就是一个很好的例子，其中的资源包应该被安装到各自网站的子目录。在这里我们使用 composer/installers 来覆盖安装路径：
{ "extra": { "installer-paths": { "sites/example.com/modules/{$name}": ["vendor/package"] } }}现在该资源包将被安装到你指定的目录，并替换 $name 变量，而不是默认目录。
注意： 你不能通过它改变所有包的安装目录。这仅适用于引入
composer/installers依赖，自定义了 type 属性的资源包。
一般情况下 不建议。vendor 目录（或者你安装依赖的其它目录）都应该被添加进 .gitignore/svn:ignore/等等。
最好这么做，然后让所有开发人员使用 Composer 来安装依赖包。同样，build server、CI、deployment tools 等等，应进行修改，使运行 Composer 成为其项目引导的一部分。
虽然在某些环境下提交它是很让人心动的，但它将导致一些问题：
如果你真的觉得你必须这样做，你有几个选择：
preferred-install 为 dist。.git 文件夹，然后你就可以添加它们到你的 git repo 中。你可以运行 rm -rf vendor/**/.git 命令快捷的操作，但这意味着你在运行 composer update 命令前需要先删除磁盘中的依赖文件。vendor/.git）来忽略 vendor 下所有 .git 目录。这种方法不需要你在运行 composer update 命令前删除你磁盘中的依赖文件。每个用户界面考虑有以下三个主要方面：
UI 元素： 有用户最终看到并且与之交互的核心视觉元素。GWT 提供了一个大量的广泛使用和常见的元素列表，本教程我们将涉及从基本到复杂的变化。
布局： 他们定义应该如何在屏幕上组织 UI 元素，并且提供一个最终的外观和风格给 GUI（图形用户界面）。这部分将在布局这一章涉及。
每个 SWING 控件从下列组件类的等级继承属性。
| 序号 | 类 & 描述 |
|---|---|
| 1 | Component Container 是 SWING 的非菜单用户界面控件的一个抽象基类。组件代表一个用图形表示的对象 |
| 2 | Container Container 是一个组件，它可以包含其他 SWING 组件。 |
| 3 | JComponent JComponent 是一个所有 swing UI 组件的基类。为了使用继承自 JComponent 的一个 swing 组件，组件必须是一个包容层次结构，它的根是一个顶层的 Swing 容器。 |
下列是当使用 SWING 来设计 GUI 时常用的控件列表。
| Sr. No. | 控件 & 描述 |
|---|---|
| 1 | JLabel JLabel 对象是一个在容器中放置文本的组件。 |
| 2 | JButton 该类创建一个有标签的的按钮。 |
| 3 | JColorChooser JColorChooser 提供一个控制面板，设计允许用户操作和选择颜色。 |
| 4 | JCheck Box JCheckBox 是一个图形化的组件，它的状态要么是 on（true）要么是 off（false）。 |
| 5 | JRadioButton JRadioButton 类是一个图形化的组件，在一个组中，它的状态要么是 on（true）要么是off（false）。 |
| 6 | JList JList 组件呈现给用户一个滚动的文本项列表。 |
| 7 | JComboBox JComboBox 组件呈现给用户一个显示菜单的选择。 |
| 8 | JTextField JTextField 对象是一个文本组件，它允许编辑单行文本。 |
| 9 | JPasswordField JPasswordField 对象是一个专门用于密码输入的文本组件。 |
| 10 | JTextArea JTextArea 对象是一个文本组件，它允许编辑多行文本。 |
| 11 | ImageIcon ImageIcon 控件是一个图标界面的实现，它从图像描绘图标 |
| 12 | JScrollbar Scrollbar 控件代表一个滚动条组件，为了让用户从值的范围中选择。 |
| 13 | JOptionPane JOptionPane 提供了一组提示用户输入值的标准对话框，或者通知他们其他东西。 |
| 14 | JFileChooser JFileChooser 控件代表一个对话框窗口，用户可以从该对话框窗口选择一个文件。 |
| 15 | JProgressBar 随着任务完成的进展，进度条显示任务完成的百分比。 |
| 16 | JSlider JSlider 让用户在有界区间内通过滑动旋钮图形化地选择一个值。 |
| 17 | JSpinner JSpinner 是一个单行输入字段，它让用户从一个有序序列中选择一个数字或者一个对象值。 |
当你使用自定义库时，你可能会碰到问题，因为 Composer 不会递归加载你要求的储存库，所以你必须修改这些储存库中所有的 composer.json 文件。
在详细说明为什么是这样之前，你需要明白：使用自定义 VCS & 包储存库去尝试某些事情，或者使用你 fork 的一个分支，直到你的 pull request 被合并，等等。你不应该使用它们来跟踪你的私人资源包，关于这点你应该看看 setting up Satis 来为你的公司甚至自己处理私人资源包。
这里有三个途径可以使依赖解析器使用你自定义的储存库：
读取根包的存储库，从定义的存储库得到所有的软件包，解析依赖需求。这是目前的状态，它工作得很好，除了有“无法递归的加载储存库”这个限制。
读取根包的存储库，同时从定义的 repos 初始化资源包，递归的初始化，根据所有依赖包中定义的 repos，以及这些依赖包所依赖的其它包中定义的 repos，等等，然后再解析依赖需求。这可能可以工作，但会严重影响初始化的速度，因为每读取一个 VCS repos 都需要几秒钟。它可能最终执行失败，因为一个包的不同版本，可能来自一个包资源库中一个相同的包，但来至不同的 dist/source 。这样有太多的可能会出错。
安装 Composer，你只需要下载 composer.phar 可执行文件。
curl -sS https://getcomposer.org/installer | php详细请查看 简介 章节。
要检查 Composer 是否正常工作，只需要通过 php 来执行 PHAR：
php composer.phar这将返回给你一个可执行的命令列表。
**注意：** 你也可以仅执行 `--check` 选项而无需下载 Composer。 要获取更多的信息请使用 `--help`。 curl -sS https://getcomposer.org/installer | php -- --help >要开始在你的项目中使用 Composer，你只需要一个 composer.json 文件。该文件包含了项目的依赖和其它的一些元数据。
这个 JSON format 是很容易编写的。它允许你定义嵌套结构。
第一件事情（并且往往只需要做这一件事），你需要在 composer.json 文件中指定 require key 的值。你只需要简单的告诉 Composer 你的项目需要依赖哪些包。
{ "require": { "monolog/monolog": "1.0.*" }}你可以看到， require 需要一个 包名称 （例如 monolog/monolog） 映射到 包版本 （例如 1.0.*） 的对象。
包名称由供应商名称和其项目名称构成。通常容易产生相同的项目名称，而供应商名称的存在则很好的解决了命名冲突的问题。它允许两个不同的人创建同样名为 json 的库，而之后它们将被命名为 igorw/json 和 seldaek/json。
这里我们需要引入 monolog/monolog，供应商名称与项目的名称相同，对于一个具有唯一名称的项目，我们推荐这么做。它还允许以后在同一个命名空间添加更多的相关项目。如果你维护着一个库，这将使你可以很容易的把它分离成更小的部分。
在前面的例子中，我们引入的 monolog 版本指定为 1.0.*。这表示任何从 1.0 开始的开发分支，它将会匹配 1.0.0、1.0.2 或者 1.0.20。
版本约束可以用几个不同的方法来指定。
| 名称 | 实例 | 描述 |
|---|---|---|
| 确切的版本号 | `1.0.2` | 你可以指定包的确切版本。 |
| 范围 | `>=1.0` `>=1.0,=1.0,=1.2` | 通过使用比较操作符可以指定有效的版本范围。 有效的运算符：`>`、`>=`、` |
| 通配符 | `1.0.*` | 你可以使用通配符`*`来指定一种模式。`1.0.*`与`>=1.0, |
| 赋值运算符 | `~1.2` | 这对于遵循语义化版本号的项目非常有用。`~1.2`相当于`>=1.2, |
~ 最好用例子来解释： ~1.2 相当于 >=1.2,<2.0，而 ~1.2.3 相当于 >=1.2.3,<1.3。正如你所看到的这对于遵循 语义化版本号 的项目最有用。一个常见的用法是标记你所依赖的最低版本，像 ~1.2 （允许1.2以上的任何版本，但不包括2.0）。由于理论上直到2.0应该都没有向后兼容性问题，所以效果很好。你还会看到它的另一种用法，使用 ~ 指定最低版本，但允许版本号的最后一位数字上升。
注意： 虽然
2.0-beta.1严格地说是早于2.0，但是，根据版本约束条件， 例如~1.2却不会安装这个版本。就像前面所讲的~1.2只意味着.2部分可以改变，但是1.部分是固定的。
默认情况下只有稳定的发行版才会被考虑在内。如果你也想获得 RC、beta、alpha 或 dev 版本，你可以使用 稳定标志。你可以对所有的包做 最小稳定性 设置，而不是每个依赖逐一设置。
获取定义的依赖到你的本地项目，只需要调用 composer.phar 运行 install 命令。
php composer.phar install接着前面的例子，这将会找到 monolog/monolog 的最新版本，并将它下载到 vendor 目录。 这是一个惯例把第三方的代码到一个指定的目录 vendor。如果是 monolog 将会创建 vendor/monolog/monolog 目录。
小技巧： 如果你正在使用Git来管理你的项目， 你可能要添加
vendor到你的.gitignore文件中。 你不会希望将所有的代码都添加到你的版本库中。
另一件事是 install 命令将创建一个 composer.lock 文件到你项目的根目录中。
composer.lock - 锁文件在安装依赖后，Composer 将把安装时确切的版本号列表写入 composer.lock 文件。这将锁定改项目的特定版本。
请提交你应用程序的 composer.lock （包括 composer.json）到你的版本库中
这是非常重要的，因为 install 命令将会检查锁文件是否存在，如果存在，它将下载指定的版本（忽略 composer.json 文件中的定义）。
这意味着，任何人建立项目都将下载与指定版本完全相同的依赖。你的持续集成服务器、生产环境、你团队中的其他开发人员、每件事、每个人都使用相同的依赖，从而减轻潜在的错误对部署的影响。即使你独自开发项目，在六个月内重新安装项目时，你也可以放心的继续工作，即使从那时起你的依赖已经发布了许多新的版本。
如果不存在 composer.lock 文件，Composer 将读取 composer.json 并创建锁文件。
这意味着如果你的依赖更新了新的版本，你将不会获得任何更新。此时要更新你的依赖版本请使用 update 命令。这将获取最新匹配的版本（根据你的 composer.json 文件）并将新版本更新进锁文件。
php composer.phar update如果只想安装或更新一个依赖，你可以白名单它们：
php composer.phar update monolog/monolog [...]注意： 对于库，并不一定建议提交锁文件 请参考：库的锁文件.
packagist 是 Composer 的主要资源库。 一个 Composer 的库基本上是一个包的源：记录了可以得到包的地方。Packagist 的目标是成为大家使用库资源的中央存储平台。这意味着你可以 require 那里的任何包。
当你访问 packagist website (packagist.org)，你可以浏览和搜索资源包。
任何支持 Composer 的开源项目应该发布自己的包在 packagist 上。虽然并不一定要发布在 packagist 上来使用 Composer，但它使我们的编程生活更加轻松。
对于库的自动加载信息，Composer 生成了一个 vendor/autoload.php 文件。你可以简单的引入这个文件，你会得到一个免费的自动加载支持。
require 'vendor/autoload.php';这使得你可以很容易的使用第三方代码。例如：如果你的项目依赖 monolog，你就可以像这样开始使用这个类库，并且他们将被自动加载。
$log = new MonologLogger('name');$log->pushHandler(new MonologHandlerStreamHandler('app.log', MonologLogger::WARNING));$log->addWarning('Foo');你可以在 composer.json 的 autoload 字段中增加自己的 autoloader。
{ "autoload": { "psr-4": {"Acme": "src/"} }}Composer 将注册一个 PSR-4 autoloader 到 Acme 命名空间。
你可以定义一个从命名空间到目录的映射。此时 src 会在你项目的根目录，与 vendor 文件夹同级。例如 src/Foo.php 文件应该包含 AcmeFoo 类。
添加 autoload 字段后，你应该再次运行 install 命令来生成 vendor/autoload.php 文件。
引用这个文件也将返回 autoloader 的实例，你可以将包含调用的返回值存储在变量中，并添加更多的命名空间。这对于在一个测试套件中自动加载类文件是非常有用的，例如。
$loader = require 'vendor/autoload.php';$loader->add('AcmeTest', __DIR__);除了 PSR-4 自动加载，classmap 也是支持的。这允许类被自动加载，即使不符合 PSR-0 规范。详细请查看 自动加载-参考。
注意： Composer 提供了自己的 autoloader。如果你不想使用它，你可以仅仅引入 vendor/composer/autoload_*.php 文件，它返回一个关联数组，你可以通过这个关联数组配置自己的 autoloader。
本章将解释所有在 composer.json 中可用的字段。
我们有一个 JSON schema 格式化文档，它也可以被用来验证你的 composer.json 文件。事实上，它已经被 validate 命令所使用。 你可以在这里找到它： res/composer-schema.json.
“root 包”是指由 composer.json 定义的在你项目根目录的包。这是 composer.json 定义你项目所需的主要条件。（简单的说，你自己的项目就是一个 root 包）
某些字段仅适用于“root 包”上下文。 config 字段就是其中一个例子。只有“root 包”可以定义。在依赖包中定义的 config 字段将被忽略，这使得 config 字段只有“root 包”可用（root-only）。
如果你克隆了其中的一个依赖包，直接在其上开始工作，那么它就变成了“root 包”。与作为他人的依赖包时使用相同的 composer.json 文件，但上下文发生了变化。
注意： 一个资源包是不是“root 包”，取决于它的上下文。 例：如果你的项目依赖
monolog库，那么你的项目就是“root 包”。 但是，如果你从 GitHub 上克隆了monolog为它修复 bug， 那么此时monolog就是“root 包”。
包的名称，它包括供应商名称和项目名称，使用 / 分隔。
例：
对于需要发布的包（库），这是必须填写的。
一个包的简短描述。通常这个最长只有一行。
对于需要发布的包（库），这是必须填写的。
version 不是必须的，并且建议忽略（见下文）。
它应该符合 'X.Y.Z' 或者 'vX.Y.Z' 的形式， -dev、-patch、-alpha、-beta 或 -RC 这些后缀是可选的。在后缀之后也可以再跟上一个数字。
例：
通常，我们能够从 VCS (git, svn, hg) 的信息推断出包的版本号，在这种情况下，我们建议忽略 version。
注意： Packagist 使用 VCS 仓库， 因此
version定义的版本号必须是真实准确的。 自己手动指定的version，最终有可能在某个时候因为人为错误造成问题。
包的安装类型，默认为 library。
包的安装类型，用来定义安装逻辑。如果你有一个包需要一个特殊的逻辑，你可以设定一个自定义的类型。这可以是一个 symfony-bundle，一个 wordpress-plugin 或者一个 typo3-module。这些类型都将是具体到某一个项目，而对应的项目将要提供一种能够安装该类型包的安装程序。
composer 原生支持以下4种类型：
vendor 目录。composer-plugin 的包，它有一个自定义安装类型，可以为其它包提供一个 installler。详细请查看 自定义安装类型。仅在你需要一个自定义的安装逻辑时才使用它。建议忽略这个属性，采用默认的 library。
keywords该包相关的关键词的数组。这些可用于搜索和过滤。
实例：
可选。
该项目网站的 URL 地址。
可选。
版本发布时间。
必须符合 YYYY-MM-DD 或 YYYY-MM-DD HH:MM:SS 格式。
可选。
包的许可协议，它可以是一个字符串或者字符串数组。
最常见的许可协议的推荐写法（按字母排序）：
可选，但强烈建议提供此内容。更多许可协议的标识符请参见 SPDX Open Source License Registry。
对于闭源软件，你必须使用 "proprietary" 协议标识符。
一个例：
{ "license": "MIT"}对于一个包，当允许在多个许可协议间进行选择时（"disjunctive license"），这些协议标识符可以被指定为数组。
多协议的一个例：
{ "license": [ "LGPL-2.1", "GPL-3.0+" ]}另外它们也可以由 "or" 分隔，并写在括号中：
{ "license": "(LGPL-2.1 or GPL-3.0+)"}同样，当有多个许可协议需要结合使用时（"conjunctive license"），它们应该被 "and" 分隔，并写在括号中。
包的作者。这是一个对象数组。
这个对象必须包含以下属性：
一个实例：
{ "authors": [ { "name": "Nils Adermann", "email": "naderman@naderman.de", "homepage": "http://www.naderman.de", "role": "Developer" }, { "name": "Jordi Boggiano", "email": "j.boggiano@seld.be", "homepage": "http://seld.be", "role": "Developer" } ]}可选，但强烈建议提供此内容。
获取项目支持的向相关信息对象。
这个对象必须包含以下属性：
一个实例：
{ "support": { "email": "support@example.org", "irc": "irc://irc.freenode.org/composer" }}可选。
下面提到的所有对象，都应该是 包名 到 版本 的映射对象。
实例：
{ "require": { "monolog/monolog": "1.0.*" }}所有的这些都是可选的。
require 和 require-dev 还支持稳定性标签（@，仅针对“root 包”）。这允许你在 minimum-stability设定的范围外做进一步的限制或扩展。例：如果你想允许依赖一个不稳定的包，你可以在一个包的版本约束后使用它，或者是一个空的版本约束内使用它。
实例：
{ "require": { "monolog/monolog": "1.0.*@beta", "acme/foo": "@dev" }}如果你的依赖之一，有对另一个不稳定包的依赖，你最好在 require 中显示的定义它，并带上足够详细的稳定性标识。
实例：
{ "require": { "doctrine/doctrine-fixtures-bundle": "dev-master", "doctrine/data-fixtures": "@dev" }}require 和 require-dev 还支持对 dev（开发）版本的明确引用（即：版本控制系统中的提交编号 commit），以确保它们被锁定到一个给定的状态，即使你运行了更新命令。你只需要明确一个开发版本号，并带上诸如 #<ref> 的标识。
实例：
{ "require": { "monolog/monolog": "dev-master#2eb0c0978d290a1c45346a1955188929cb4e5db7", "acme/foo": "1.0.x-dev#abc123" }}注意： 虽然这有时很方便，但不应该长期在你的包中使用，因为它有一个技术上的限制。 composer.json 将仍然在哈希值之前指定的分支名称读取元数据， 正因为如此，在某些情况下，它不会是一个实用的解决方法， 如果可能，你应该总是尝试切换到拥有标签的版本。
它也可以应用于行内别名，这样它将匹配一个约束，否则不会。更多信息请参考 别名。
必须的软件包列表，除非这些依赖被满足，否则不会完成安装。
这个列表是为开发或测试等目的，额外列出的依赖。“root 包”的 require-dev 默认是会被安装的。然而 install 或 update 支持使用 --no-dev 参数来跳过 require-dev 字段中列出的包。
此列表中的包与当前包的这个版本冲突。它们将不允许同时被安装。
请注意，在 conflict 中指定类似于 <1.0, >= 1.1 的版本范围时，这表示它与小于1.0 并且 同时大等于1.1的版本冲突，这很可能不是你想要的。在这种情况下你可能想要表达的是 <1.0 | >= 1.1 。
这个列表中的包将被当前包取代。这使你可以 fork 一个包，以不同的名称和版本号发布，同时要求依赖于原包的其它包，在这之后依赖于你 fork 的这个包，因为它取代了原来的包。
这对于创建一个内部包含子包的主包也非常的有用。例如 symfony/symfony 这个主包，包含了所有 Symfony 的组件，而这些组件又可以作为单独的包进行发布。如果你 require 了主包，那么它就会自动完成其下各个组件的任务，因为主包取代了子包。
注意，在使用上述方法取代子包时，通常你应该只对子包使用 self.version 这一个版本约束，以确保主包仅替换掉子包的准确版本，而不是任何其他版本。
List of other packages that are provided by this package. This is mostly useful for common interfaces. A package could depend on some virtual logger package, any library that implements this logger interface would simply list it in provide.
建议安装的包，它们增强或能够与当前包良好的工作。这些只是信息，并显示在依赖包安装完成之后，给你的用户一个建议，他们可以添加更多的包。
格式如下，版本约束变成了描述信息。
实例：
{ "suggest": { "monolog/monolog": "Allows more advanced logging of the application flow" }}PHP autoloader 的自动加载映射。
Currently PSR-0 autoloading, PSR-4 autoloading, classmap generation and files includes are supported. PSR-4 is the recommended way though since it offers greater ease of use (no need to regenerate the autoloader when you add classes).
Under the psr-4 key you define a mapping from namespaces to paths, relative to the package root. When autoloading a class like FooBarBaz a namespace prefix Foo pointing to a directory src/ means that the autoloader will look for a file named src/Bar/Baz.php and include it if present. Note that as opposed to the older PSR-0 style, the prefix (Foo) is not present in the file path.
Namespace prefixes must end in to avoid conflicts between similar prefixes. For example Foo would match classes in the FooBar namespace so the trailing backslashes solve the problem: Foo and FooBar are distinct.
The PSR-4 references are all combined, during install/update, into a single key => value array which may be found in the generated file vendor/composer/autoload_psr4.php.
Example:
{ "autoload": { "psr-4": { "Monolog": "src/", "VendorNamespace": "" } }}If you need to search for a same prefix in multiple directories, you can specify them as an array as such:
{ "autoload": { "psr-4": { "Monolog": ["src/", "lib/"] } }}If you want to have a fallback directory where any namespace will be looked for, you can use an empty prefix like:
{ "autoload": { "psr-4": { "": "src/" } }}在 psr-0 key 下你定义了一个命名空间到实际路径的映射（相对于包的根目录）。注意，这里同样支持 PEAR-style 方式的约定（与命名空间不同，PEAR 类库在类名上采用了下划线分隔）。
请注意，命名空间的申明应该以 结束，以确保 autoloader 能够准确响应。例： Foo 将会与 FooBar 匹配，然而以反斜杠结束就可以解决这样的问题， Foo 和 FooBar 将会被区分开来。
在 install/update 过程中，PSR-0 引用都将被结合为一个单一的键值对数组，存储至 vendor/composer/autoload_namespaces.php 文件中。
实例：
{ "autoload": { "psr-0": { "Monolog": "src/", "VendorNamespace": "src/", "Vendor_Namespace_": "src/" } }}如果你需要搜索多个目录中一个相同的前缀，你可以将它们指定为一个数组，例：
{ "autoload": { "psr-0": { "Monolog": ["src/", "lib/"] } }}PSR-0 方式并不仅限于申明命名空间，也可以是精确到类级别的指定。这对于只有一个类在全局命名空间的类库是非常有用的（如果 php 源文件也位于包的根目录）。例如，可以这样申明：
{ "autoload": { "psr-0": { "UniqueGlobalClass": "" } }}如果你想设置一个目录作为任何命名空间的备用目录，你可以使用空的前缀，像这样：
{ "autoload": { "psr-0": { "": "src/" } }}classmap 引用的所有组合，都会在 install/update 过程中生成，并存储到 vendor/composer/autoload_classmap.php 文件中。这个 map 是经过扫描指定目录（同样支持直接精确到文件）中所有的 .php 和 .inc 文件里内置的类而得到的。
你可以用 classmap 生成支持支持自定义加载的不遵循 PSR-0/4 规范的类库。要配置它指向需要的目录，以便能够准确搜索到类文件。
实例：
{ "autoload": { "classmap": ["src/", "lib/", "Something.php"] }}如果你想要明确的指定，在每次请求时都要载入某些文件，那么你可以使用 'files' autoloading。通常作为函数库的载入方式（而非类库）。
实例：
{ "autoload": { "files": ["src/MyLibrary/functions.php"] }}This section allows to define autoload rules for development purposes.
Classes needed to run the test suite should not be included in the main autoload rules to avoid polluting the autoloader in production and when other people use your package as a dependency.
Therefore, it is a good idea to rely on a dedicated path for your unit tests and to add it within the autoload-dev section.
Example:
{ "autoload": { "psr-4": { "MyLibrary": "src/" } }, "autoload-dev": { "psr-4": { "MyLibraryTests": "tests/" } }}不建议：这是目前唯一支持传统项目的做法，所有新的代码都建议使用自动加载。 这是一个过时的做法，但 Composer 将仍然保留这个功能。
一个追加到 PHP include_path 中的列表。
实例：
{ "include-path": ["lib/"]}可选。
DEPRECATED: This is only present to support legacy PSR-0 style autoloading, and all new code should preferably use PSR-4 without target-dir and projects using PSR-0 with PHP namespaces are encouraged to migrate to PSR-4 instead.
定义当前包安装的目标文件夹。
若某个包的根目录，在它申明的命名空间之下，将不能正确的使用自动加载。而 target-dir 解决了这个问题。
Symfony 就是一个例子。它有一些独立的包作为组件。Yaml 组件就放在 SymfonyComponentYaml 目录下，然而这个包的根目录实际上是 Yaml。为了使自动加载成为可能，我们需要确保它不会被安装到 vendor/symfony/yaml，而是安装到 vendor/symfony/yaml/Symfony/Component/Yaml，从而使 Symfony 定义的 autoloader 可以从 vendor/symfony/yaml 加载它。
要做到这一点 autoload 和 target-dir 应该定义如下：
{ "autoload": { "psr-0": { "SymfonyComponentYaml": "" } }, "target-dir": "Symfony/Component/Yaml"}可选。
这定义了通过稳定性过滤包的默认行为。默认为 stable（稳定）。因此如果你依赖于一个 dev（开发）包，你应该明确的进行定义。
对每个包的所有版本都会进行稳定性检查，而低于 minimum-stability 所设定的最低稳定性的版本，将在解决依赖关系时被忽略。对于个别包的特殊稳定性要求，可以在 require 或 require-dev 中设定（请参考 Package links）。
可用的稳定性标识（按字母排序）：dev、alpha、beta、RC、stable。
当此选项被激活时，Composer 将优先使用更稳定的包版本。
使用 "prefer-stable": true 来激活它。
使用自定义的包资源库。
默认情况下 composer 只使用 packagist 作为包的资源库。通过指定资源库，你可以从其他地方获取资源包。
Repositories 并不是递归调用的，只能在“Root包”的 composer.json 中定义。附属包中的 composer.json 将被忽略。
支持以下类型的包资源库：
packages.json 文件，它包含一个 composer.json 对象的列表，有额外的 dist 和/或 source 信息。这个 packages.json 文件是用一个 PHP 流加载的。你可以使用 options 参数来设定额外的流信息。composer.json 对象。更多相关内容，请查看 资源库。
实例：
{ "repositories": [ { "type": "composer", "url": "http://packages.example.com" }, { "type": "composer", "url": "https://packages.example.com", "options": { "ssl": { "verify_peer": "true" } } }, { "type": "vcs", "url": "https://github.com/Seldaek/monolog" }, { "type": "pear", "url": "http://pear2.php.net" }, { "type": "package", "package": { "name": "smarty/smarty", "version": "3.1.7", "dist": { "url": "http://www.smarty.net/files/Smarty-3.1.7.zip", "type": "zip" }, "source": { "url": "http://smarty-php.googlecode.com/svn/", "type": "svn", "reference": "tags/Smarty_3_1_7/distribution/" } } } ]}注意： 顺序是非常重要的，当 Composer 查找资源包时，它会按照顺序进行。默认情况下 Packagist 是最后加入的，因此自定义设置将可以覆盖 Packagist 上的包。
下面的这一组选项，仅用于项目。
支持以下选项：
300。处理进程结束时间，例如：git 克隆的时间。Composer 将放弃超时的任务。如果你的网络缓慢或者正在使用一个巨大的包，你可能要将这个值设置的更高一些。false。如果为 true，Composer autoloader 还将在 PHP include path 中继续查找类文件。auto。它的值可以是 source、dist 或 auto。这个选项允许你设置 Composer 的默认安装方法。["git", "https", "ssh"]。从 github.com 克隆时使用的协议优先级清单，因此默认情况下将优先使用 git 协议进行克隆。你可以重新排列它们的次序，例如，如果你的网络有代理服务器或 git 协议的效率很低，你就可以提升 https 协议的优先级。{"github.com": "oauthtoken"} 作为此选项的值， 将使用 oauthtoken 来访问 github 上的私人仓库，并绕过 low IP-based rate 的 API 限制。 关联知识关于如何获取 GitHub 的 OAuth token。vendor。通过设置你可以安装依赖到不同的目录。vendor/bin。如果一个项目包含二进制文件，它们将被连接到这个目录。$home/cache，Windows 下默认为 C:Users<user>AppDataLocalComposer。用于存储 composer 所有的缓存文件。相关信息请查看 COMPOSER_HOME。$cache-dir/files。存储包 zip 存档的目录。$cache-dir/repo。存储 composer 类型的 VCS（svn、github、bitbucket） repos 目录。$cache-dir/vcs。此目录用于存储 VCS 克隆的 git/hg 类型的元数据，并加快安装速度。15552000（6个月）。默认情况下 Composer 缓存的所有数据都将在闲置6个月后被删除，这个选项允许你来调整这个时间，你可以将其设置为0以禁用缓存。300MiB。Composer 缓存的最大容量，超出后将优先清除旧的缓存数据，直到缓存量低于这个数值。true。如果设置为 false，composer autoloader 将不会附加到现有的自动加载机制中。这有时候用来解决与其它自动加载机制产生的冲突。null。Composer autoloader 的后缀，当设置为空时将会产生一个随机的字符串。false. Always optimize when dumping the autoloader.["github.com"]。一个 github mode 下的域名列表。这是用于GitHub的企业设置。true。Composer 允许资源仓库定义一个用于通知的 URL，以便有人从其上安装资源包时能够得到一个反馈通知。此选项允许你禁用该行为。false，它的值可以是 true、false 或 stash。这个选项允许你设置在非交互模式下，当处理失败的更新时采用的处理方式。true 表示永远放弃更改。"stash" 表示继续尝试。Use this for CI servers or deploy scripts if you tend to have modified vendors.实例：
{ "config": { "bin-dir": "bin" }}Composer 允许你在安装过程中的各个阶段挂接脚本。
更多细节和案例请查看 脚本。
任意的，供 scripts 使用的额外数据。.
这可以是几乎任何东西。若要从脚本事件访问处理程序，你可以这样做：
$extra = $event->getComposer()->getPackage()->getExtra();可选。
该属性用于标注一组应被视为二进制脚本的文件，他们会被软链接到（config 对象中的）bin-dir 属性所标注的目录，以供其他依赖包调用。
详细请查看 Vendor Binaries。
可选。
这些选项在创建包存档时使用。
支持以下选项：
实例：
{ "archive": { "exclude": ["/foo/bar", "baz", "/*.test", "!/foo/bar/baz"] }}在这个例子中我们 include /dir/foo/bar/file、/foo/bar/baz、/file.php、/foo/my.test 但排除了 /foo/bar/any、/foo/baz、/my.test。
可选。
安装 Composer，你只需要下载 composer.phar 可执行文件。
curl -sS https://getcomposer.org/installer | php详细请查看 简介 章节。
要检查 Composer 是否正常工作，只需要通过 php 来执行 PHAR：
php composer.phar这将返回给你一个可执行的命令列表。
**注意：** 你也可以仅执行 `--check` 选项而无需下载 Composer。 要获取更多的信息请使用 `--help`。 curl -sS https://getcomposer.org/installer | php -- --help >要开始在你的项目中使用 Composer，你只需要一个 composer.json 文件。该文件包含了项目的依赖和其它的一些元数据。
这个 JSON format 是很容易编写的。它允许你定义嵌套结构。
第一件事情（并且往往只需要做这一件事），你需要在 composer.json 文件中指定 require key 的值。你只需要简单的告诉 Composer 你的项目需要依赖哪些包。
{ "require": { "monolog/monolog": "1.0.*" }}你可以看到， require 需要一个 包名称 （例如 monolog/monolog） 映射到 包版本 （例如 1.0.*） 的对象。
包名称由供应商名称和其项目名称构成。通常容易产生相同的项目名称，而供应商名称的存在则很好的解决了命名冲突的问题。它允许两个不同的人创建同样名为 json 的库，而之后它们将被命名为 igorw/json 和 seldaek/json。
这里我们需要引入 monolog/monolog，供应商名称与项目的名称相同，对于一个具有唯一名称的项目，我们推荐这么做。它还允许以后在同一个命名空间添加更多的相关项目。如果你维护着一个库，这将使你可以很容易的把它分离成更小的部分。
在前面的例子中，我们引入的 monolog 版本指定为 1.0.*。这表示任何从 1.0 开始的开发分支，它将会匹配 1.0.0、1.0.2 或者 1.0.20。
版本约束可以用几个不同的方法来指定。
| 名称 | 实例 | 描述 |
|---|---|---|
| 确切的版本号 | `1.0.2` | 你可以指定包的确切版本。 |
| 范围 | `>=1.0` `>=1.0,=1.0,=1.2` | 通过使用比较操作符可以指定有效的版本范围。 有效的运算符：`>`、`>=`、` |
| 通配符 | `1.0.*` | 你可以使用通配符`*`来指定一种模式。`1.0.*`与`>=1.0, |
| 赋值运算符 | `~1.2` | 这对于遵循语义化版本号的项目非常有用。`~1.2`相当于`>=1.2, |
~ 最好用例子来解释： ~1.2 相当于 >=1.2,<2.0，而 ~1.2.3 相当于 >=1.2.3,<1.3。正如你所看到的这对于遵循 语义化版本号 的项目最有用。一个常见的用法是标记你所依赖的最低版本，像 ~1.2 （允许1.2以上的任何版本，但不包括2.0）。由于理论上直到2.0应该都没有向后兼容性问题，所以效果很好。你还会看到它的另一种用法，使用 ~ 指定最低版本，但允许版本号的最后一位数字上升。
注意： 虽然
2.0-beta.1严格地说是早于2.0，但是，根据版本约束条件， 例如~1.2却不会安装这个版本。就像前面所讲的~1.2只意味着.2部分可以改变，但是1.部分是固定的。
默认情况下只有稳定的发行版才会被考虑在内。如果你也想获得 RC、beta、alpha 或 dev 版本，你可以使用 稳定标志。你可以对所有的包做 最小稳定性 设置，而不是每个依赖逐一设置。
获取定义的依赖到你的本地项目，只需要调用 composer.phar 运行 install 命令。
php composer.phar install接着前面的例子，这将会找到 monolog/monolog 的最新版本，并将它下载到 vendor 目录。 这是一个惯例把第三方的代码到一个指定的目录 vendor。如果是 monolog 将会创建 vendor/monolog/monolog 目录。
小技巧： 如果你正在使用Git来管理你的项目， 你可能要添加
vendor到你的.gitignore文件中。 你不会希望将所有的代码都添加到你的版本库中。
另一件事是 install 命令将创建一个 composer.lock 文件到你项目的根目录中。
composer.lock - 锁文件在安装依赖后，Composer 将把安装时确切的版本号列表写入 composer.lock 文件。这将锁定改项目的特定版本。
请提交你应用程序的 composer.lock （包括 composer.json）到你的版本库中
这是非常重要的，因为 install 命令将会检查锁文件是否存在，如果存在，它将下载指定的版本（忽略 composer.json 文件中的定义）。
这意味着，任何人建立项目都将下载与指定版本完全相同的依赖。你的持续集成服务器、生产环境、你团队中的其他开发人员、每件事、每个人都使用相同的依赖，从而减轻潜在的错误对部署的影响。即使你独自开发项目，在六个月内重新安装项目时，你也可以放心的继续工作，即使从那时起你的依赖已经发布了许多新的版本。
如果不存在 composer.lock 文件，Composer 将读取 composer.json 并创建锁文件。
这意味着如果你的依赖更新了新的版本，你将不会获得任何更新。此时要更新你的依赖版本请使用 update 命令。这将获取最新匹配的版本（根据你的 composer.json 文件）并将新版本更新进锁文件。
php composer.phar update如果只想安装或更新一个依赖，你可以白名单它们：
php composer.phar update monolog/monolog [...]注意： 对于库，并不一定建议提交锁文件 请参考：库的锁文件.
packagist 是 Composer 的主要资源库。 一个 Composer 的库基本上是一个包的源：记录了可以得到包的地方。Packagist 的目标是成为大家使用库资源的中央存储平台。这意味着你可以 require 那里的任何包。
当你访问 packagist website (packagist.org)，你可以浏览和搜索资源包。
任何支持 Composer 的开源项目应该发布自己的包在 packagist 上。虽然并不一定要发布在 packagist 上来使用 Composer，但它使我们的编程生活更加轻松。
对于库的自动加载信息，Composer 生成了一个 vendor/autoload.php 文件。你可以简单的引入这个文件，你会得到一个免费的自动加载支持。
require 'vendor/autoload.php';这使得你可以很容易的使用第三方代码。例如：如果你的项目依赖 monolog，你就可以像这样开始使用这个类库，并且他们将被自动加载。
$log = new MonologLogger('name');$log->pushHandler(new MonologHandlerStreamHandler('app.log', MonologLogger::WARNING));$log->addWarning('Foo');你可以在 composer.json 的 autoload 字段中增加自己的 autoloader。
{ "autoload": { "psr-4": {"Acme": "src/"} }}Composer 将注册一个 PSR-4 autoloader 到 Acme 命名空间。
你可以定义一个从命名空间到目录的映射。此时 src 会在你项目的根目录，与 vendor 文件夹同级。例如 src/Foo.php 文件应该包含 AcmeFoo 类。
添加 autoload 字段后，你应该再次运行 install 命令来生成 vendor/autoload.php 文件。
引用这个文件也将返回 autoloader 的实例，你可以将包含调用的返回值存储在变量中，并添加更多的命名空间。这对于在一个测试套件中自动加载类文件是非常有用的，例如。
$loader = require 'vendor/autoload.php';$loader->add('AcmeTest', __DIR__);除了 PSR-4 自动加载，classmap 也是支持的。这允许类被自动加载，即使不符合 PSR-0 规范。详细请查看 自动加载-参考。
注意： Composer 提供了自己的 autoloader。如果你不想使用它，你可以仅仅引入 vendor/composer/autoload_*.php 文件，它返回一个关联数组，你可以通过这个关联数组配置自己的 autoloader。
本章将解释所有在 composer.json 中可用的字段。
我们有一个 JSON schema 格式化文档，它也可以被用来验证你的 composer.json 文件。事实上，它已经被 validate 命令所使用。 你可以在这里找到它： res/composer-schema.json.
“root 包”是指由 composer.json 定义的在你项目根目录的包。这是 composer.json 定义你项目所需的主要条件。（简单的说，你自己的项目就是一个 root 包）
某些字段仅适用于“root 包”上下文。 config 字段就是其中一个例子。只有“root 包”可以定义。在依赖包中定义的 config 字段将被忽略，这使得 config 字段只有“root 包”可用（root-only）。
如果你克隆了其中的一个依赖包，直接在其上开始工作，那么它就变成了“root 包”。与作为他人的依赖包时使用相同的 composer.json 文件，但上下文发生了变化。
注意： 一个资源包是不是“root 包”，取决于它的上下文。 例：如果你的项目依赖
monolog库，那么你的项目就是“root 包”。 但是，如果你从 GitHub 上克隆了monolog为它修复 bug， 那么此时monolog就是“root 包”。
包的名称，它包括供应商名称和项目名称，使用 / 分隔。
例：
对于需要发布的包（库），这是必须填写的。
一个包的简短描述。通常这个最长只有一行。
对于需要发布的包（库），这是必须填写的。
version 不是必须的，并且建议忽略（见下文）。
它应该符合 'X.Y.Z' 或者 'vX.Y.Z' 的形式， -dev、-patch、-alpha、-beta 或 -RC 这些后缀是可选的。在后缀之后也可以再跟上一个数字。
例：
通常，我们能够从 VCS (git, svn, hg) 的信息推断出包的版本号，在这种情况下，我们建议忽略 version。
注意： Packagist 使用 VCS 仓库， 因此
version定义的版本号必须是真实准确的。 自己手动指定的version，最终有可能在某个时候因为人为错误造成问题。
包的安装类型，默认为 library。
包的安装类型，用来定义安装逻辑。如果你有一个包需要一个特殊的逻辑，你可以设定一个自定义的类型。这可以是一个 symfony-bundle，一个 wordpress-plugin 或者一个 typo3-module。这些类型都将是具体到某一个项目，而对应的项目将要提供一种能够安装该类型包的安装程序。
composer 原生支持以下4种类型：
vendor 目录。composer-plugin 的包，它有一个自定义安装类型，可以为其它包提供一个 installler。详细请查看 自定义安装类型。仅在你需要一个自定义的安装逻辑时才使用它。建议忽略这个属性，采用默认的 library。
keywords该包相关的关键词的数组。这些可用于搜索和过滤。
实例：
可选。
该项目网站的 URL 地址。
可选。
版本发布时间。
必须符合 YYYY-MM-DD 或 YYYY-MM-DD HH:MM:SS 格式。
可选。
包的许可协议，它可以是一个字符串或者字符串数组。
最常见的许可协议的推荐写法（按字母排序）：
可选，但强烈建议提供此内容。更多许可协议的标识符请参见 SPDX Open Source License Registry。
对于闭源软件，你必须使用 "proprietary" 协议标识符。
一个例：
{ "license": "MIT"}对于一个包，当允许在多个许可协议间进行选择时（"disjunctive license"），这些协议标识符可以被指定为数组。
多协议的一个例：
{ "license": [ "LGPL-2.1", "GPL-3.0+" ]}另外它们也可以由 "or" 分隔，并写在括号中：
{ "license": "(LGPL-2.1 or GPL-3.0+)"}同样，当有多个许可协议需要结合使用时（"conjunctive license"），它们应该被 "and" 分隔，并写在括号中。
包的作者。这是一个对象数组。
这个对象必须包含以下属性：
一个实例：
{ "authors": [ { "name": "Nils Adermann", "email": "naderman@naderman.de", "homepage": "http://www.naderman.de", "role": "Developer" }, { "name": "Jordi Boggiano", "email": "j.boggiano@seld.be", "homepage": "http://seld.be", "role": "Developer" } ]}可选，但强烈建议提供此内容。
获取项目支持的向相关信息对象。
这个对象必须包含以下属性：
一个实例：
{ "support": { "email": "support@example.org", "irc": "irc://irc.freenode.org/composer" }}可选。
下面提到的所有对象，都应该是 包名 到 版本 的映射对象。
实例：
{ "require": { "monolog/monolog": "1.0.*" }}所有的这些都是可选的。
require 和 require-dev 还支持稳定性标签（@，仅针对“root 包”）。这允许你在 minimum-stability设定的范围外做进一步的限制或扩展。例：如果你想允许依赖一个不稳定的包，你可以在一个包的版本约束后使用它，或者是一个空的版本约束内使用它。
实例：
{ "require": { "monolog/monolog": "1.0.*@beta", "acme/foo": "@dev" }}如果你的依赖之一，有对另一个不稳定包的依赖，你最好在 require 中显示的定义它，并带上足够详细的稳定性标识。
实例：
{ "require": { "doctrine/doctrine-fixtures-bundle": "dev-master", "doctrine/data-fixtures": "@dev" }}require 和 require-dev 还支持对 dev（开发）版本的明确引用（即：版本控制系统中的提交编号 commit），以确保它们被锁定到一个给定的状态，即使你运行了更新命令。你只需要明确一个开发版本号，并带上诸如 #<ref> 的标识。
实例：
{ "require": { "monolog/monolog": "dev-master#2eb0c0978d290a1c45346a1955188929cb4e5db7", "acme/foo": "1.0.x-dev#abc123" }}注意： 虽然这有时很方便，但不应该长期在你的包中使用，因为它有一个技术上的限制。 composer.json 将仍然在哈希值之前指定的分支名称读取元数据， 正因为如此，在某些情况下，它不会是一个实用的解决方法， 如果可能，你应该总是尝试切换到拥有标签的版本。
它也可以应用于行内别名，这样它将匹配一个约束，否则不会。更多信息请参考 别名。
必须的软件包列表，除非这些依赖被满足，否则不会完成安装。
这个列表是为开发或测试等目的，额外列出的依赖。“root 包”的 require-dev 默认是会被安装的。然而 install 或 update 支持使用 --no-dev 参数来跳过 require-dev 字段中列出的包。
此列表中的包与当前包的这个版本冲突。它们将不允许同时被安装。
请注意，在 conflict 中指定类似于 <1.0, >= 1.1 的版本范围时，这表示它与小于1.0 并且 同时大等于1.1的版本冲突，这很可能不是你想要的。在这种情况下你可能想要表达的是 <1.0 | >= 1.1 。
这个列表中的包将被当前包取代。这使你可以 fork 一个包，以不同的名称和版本号发布，同时要求依赖于原包的其它包，在这之后依赖于你 fork 的这个包，因为它取代了原来的包。
这对于创建一个内部包含子包的主包也非常的有用。例如 symfony/symfony 这个主包，包含了所有 Symfony 的组件，而这些组件又可以作为单独的包进行发布。如果你 require 了主包，那么它就会自动完成其下各个组件的任务，因为主包取代了子包。
注意，在使用上述方法取代子包时，通常你应该只对子包使用 self.version 这一个版本约束，以确保主包仅替换掉子包的准确版本，而不是任何其他版本。
List of other packages that are provided by this package. This is mostly useful for common interfaces. A package could depend on some virtual logger package, any library that implements this logger interface would simply list it in provide.
建议安装的包，它们增强或能够与当前包良好的工作。这些只是信息，并显示在依赖包安装完成之后，给你的用户一个建议，他们可以添加更多的包。
格式如下，版本约束变成了描述信息。
实例：
{ "suggest": { "monolog/monolog": "Allows more advanced logging of the application flow" }}PHP autoloader 的自动加载映射。
Currently PSR-0 autoloading, PSR-4 autoloading, classmap generation and files includes are supported. PSR-4 is the recommended way though since it offers greater ease of use (no need to regenerate the autoloader when you add classes).
Under the psr-4 key you define a mapping from namespaces to paths, relative to the package root. When autoloading a class like FooBarBaz a namespace prefix Foo pointing to a directory src/ means that the autoloader will look for a file named src/Bar/Baz.php and include it if present. Note that as opposed to the older PSR-0 style, the prefix (Foo) is not present in the file path.
Namespace prefixes must end in to avoid conflicts between similar prefixes. For example Foo would match classes in the FooBar namespace so the trailing backslashes solve the problem: Foo and FooBar are distinct.
The PSR-4 references are all combined, during install/update, into a single key => value array which may be found in the generated file vendor/composer/autoload_psr4.php.
Example:
{ "autoload": { "psr-4": { "Monolog": "src/", "VendorNamespace": "" } }}If you need to search for a same prefix in multiple directories, you can specify them as an array as such:
{ "autoload": { "psr-4": { "Monolog": ["src/", "lib/"] } }}If you want to have a fallback directory where any namespace will be looked for, you can use an empty prefix like:
{ "autoload": { "psr-4": { "": "src/" } }}在 psr-0 key 下你定义了一个命名空间到实际路径的映射（相对于包的根目录）。注意，这里同样支持 PEAR-style 方式的约定（与命名空间不同，PEAR 类库在类名上采用了下划线分隔）。
请注意，命名空间的申明应该以 结束，以确保 autoloader 能够准确响应。例： Foo 将会与 FooBar 匹配，然而以反斜杠结束就可以解决这样的问题， Foo 和 FooBar 将会被区分开来。
在 install/update 过程中，PSR-0 引用都将被结合为一个单一的键值对数组，存储至 vendor/composer/autoload_namespaces.php 文件中。
实例：
{ "autoload": { "psr-0": { "Monolog": "src/", "VendorNamespace": "src/", "Vendor_Namespace_": "src/" } }}如果你需要搜索多个目录中一个相同的前缀，你可以将它们指定为一个数组，例：
{ "autoload": { "psr-0": { "Monolog": ["src/", "lib/"] } }}PSR-0 方式并不仅限于申明命名空间，也可以是精确到类级别的指定。这对于只有一个类在全局命名空间的类库是非常有用的（如果 php 源文件也位于包的根目录）。例如，可以这样申明：
{ "autoload": { "psr-0": { "UniqueGlobalClass": "" } }}如果你想设置一个目录作为任何命名空间的备用目录，你可以使用空的前缀，像这样：
{ "autoload": { "psr-0": { "": "src/" } }}classmap 引用的所有组合，都会在 install/update 过程中生成，并存储到 vendor/composer/autoload_classmap.php 文件中。这个 map 是经过扫描指定目录（同样支持直接精确到文件）中所有的 .php 和 .inc 文件里内置的类而得到的。
你可以用 classmap 生成支持支持自定义加载的不遵循 PSR-0/4 规范的类库。要配置它指向需要的目录，以便能够准确搜索到类文件。
实例：
{ "autoload": { "classmap": ["src/", "lib/", "Something.php"] }}如果你想要明确的指定，在每次请求时都要载入某些文件，那么你可以使用 'files' autoloading。通常作为函数库的载入方式（而非类库）。
实例：
{ "autoload": { "files": ["src/MyLibrary/functions.php"] }}This section allows to define autoload rules for development purposes.
Classes needed to run the test suite should not be included in the main autoload rules to avoid polluting the autoloader in production and when other people use your package as a dependency.
Therefore, it is a good idea to rely on a dedicated path for your unit tests and to add it within the autoload-dev section.
Example:
{ "autoload": { "psr-4": { "MyLibrary": "src/" } }, "autoload-dev": { "psr-4": { "MyLibraryTests": "tests/" } }}不建议：这是目前唯一支持传统项目的做法，所有新的代码都建议使用自动加载。 这是一个过时的做法，但 Composer 将仍然保留这个功能。
一个追加到 PHP include_path 中的列表。
实例：
{ "include-path": ["lib/"]}可选。
DEPRECATED: This is only present to support legacy PSR-0 style autoloading, and all new code should preferably use PSR-4 without target-dir and projects using PSR-0 with PHP namespaces are encouraged to migrate to PSR-4 instead.
定义当前包安装的目标文件夹。
若某个包的根目录，在它申明的命名空间之下，将不能正确的使用自动加载。而 target-dir 解决了这个问题。
Symfony 就是一个例子。它有一些独立的包作为组件。Yaml 组件就放在 SymfonyComponentYaml 目录下，然而这个包的根目录实际上是 Yaml。为了使自动加载成为可能，我们需要确保它不会被安装到 vendor/symfony/yaml，而是安装到 vendor/symfony/yaml/Symfony/Component/Yaml，从而使 Symfony 定义的 autoloader 可以从 vendor/symfony/yaml 加载它。
要做到这一点 autoload 和 target-dir 应该定义如下：
{ "autoload": { "psr-0": { "SymfonyComponentYaml": "" } }, "target-dir": "Symfony/Component/Yaml"}可选。
这定义了通过稳定性过滤包的默认行为。默认为 stable（稳定）。因此如果你依赖于一个 dev（开发）包，你应该明确的进行定义。
对每个包的所有版本都会进行稳定性检查，而低于 minimum-stability 所设定的最低稳定性的版本，将在解决依赖关系时被忽略。对于个别包的特殊稳定性要求，可以在 require 或 require-dev 中设定（请参考 Package links）。
可用的稳定性标识（按字母排序）：dev、alpha、beta、RC、stable。
当此选项被激活时，Composer 将优先使用更稳定的包版本。
使用 "prefer-stable": true 来激活它。
使用自定义的包资源库。
默认情况下 composer 只使用 packagist 作为包的资源库。通过指定资源库，你可以从其他地方获取资源包。
Repositories 并不是递归调用的，只能在“Root包”的 composer.json 中定义。附属包中的 composer.json 将被忽略。
支持以下类型的包资源库：
packages.json 文件，它包含一个 composer.json 对象的列表，有额外的 dist 和/或 source 信息。这个 packages.json 文件是用一个 PHP 流加载的。你可以使用 options 参数来设定额外的流信息。composer.json 对象。更多相关内容，请查看 资源库。
实例：
{ "repositories": [ { "type": "composer", "url": "http://packages.example.com" }, { "type": "composer", "url": "https://packages.example.com", "options": { "ssl": { "verify_peer": "true" } } }, { "type": "vcs", "url": "https://github.com/Seldaek/monolog" }, { "type": "pear", "url": "http://pear2.php.net" }, { "type": "package", "package": { "name": "smarty/smarty", "version": "3.1.7", "dist": { "url": "http://www.smarty.net/files/Smarty-3.1.7.zip", "type": "zip" }, "source": { "url": "http://smarty-php.googlecode.com/svn/", "type": "svn", "reference": "tags/Smarty_3_1_7/distribution/" } } } ]}注意： 顺序是非常重要的，当 Composer 查找资源包时，它会按照顺序进行。默认情况下 Packagist 是最后加入的，因此自定义设置将可以覆盖 Packagist 上的包。
下面的这一组选项，仅用于项目。
支持以下选项：
300。处理进程结束时间，例如：git 克隆的时间。Composer 将放弃超时的任务。如果你的网络缓慢或者正在使用一个巨大的包，你可能要将这个值设置的更高一些。false。如果为 true，Composer autoloader 还将在 PHP include path 中继续查找类文件。auto。它的值可以是 source、dist 或 auto。这个选项允许你设置 Composer 的默认安装方法。["git", "https", "ssh"]。从 github.com 克隆时使用的协议优先级清单，因此默认情况下将优先使用 git 协议进行克隆。你可以重新排列它们的次序，例如，如果你的网络有代理服务器或 git 协议的效率很低，你就可以提升 https 协议的优先级。{"github.com": "oauthtoken"} 作为此选项的值， 将使用 oauthtoken 来访问 github 上的私人仓库，并绕过 low IP-based rate 的 API 限制。 关联知识关于如何获取 GitHub 的 OAuth token。vendor。通过设置你可以安装依赖到不同的目录。vendor/bin。如果一个项目包含二进制文件，它们将被连接到这个目录。$home/cache，Windows 下默认为 C:Users<user>AppDataLocalComposer。用于存储 composer 所有的缓存文件。相关信息请查看 COMPOSER_HOME。$cache-dir/files。存储包 zip 存档的目录。$cache-dir/repo。存储 composer 类型的 VCS（svn、github、bitbucket） repos 目录。$cache-dir/vcs。此目录用于存储 VCS 克隆的 git/hg 类型的元数据，并加快安装速度。15552000（6个月）。默认情况下 Composer 缓存的所有数据都将在闲置6个月后被删除，这个选项允许你来调整这个时间，你可以将其设置为0以禁用缓存。300MiB。Composer 缓存的最大容量，超出后将优先清除旧的缓存数据，直到缓存量低于这个数值。true。如果设置为 false，composer autoloader 将不会附加到现有的自动加载机制中。这有时候用来解决与其它自动加载机制产生的冲突。null。Composer autoloader 的后缀，当设置为空时将会产生一个随机的字符串。false. Always optimize when dumping the autoloader.["github.com"]。一个 github mode 下的域名列表。这是用于GitHub的企业设置。true。Composer 允许资源仓库定义一个用于通知的 URL，以便有人从其上安装资源包时能够得到一个反馈通知。此选项允许你禁用该行为。false，它的值可以是 true、false 或 stash。这个选项允许你设置在非交互模式下，当处理失败的更新时采用的处理方式。true 表示永远放弃更改。"stash" 表示继续尝试。Use this for CI servers or deploy scripts if you tend to have modified vendors.实例：
{ "config": { "bin-dir": "bin" }}Composer 允许你在安装过程中的各个阶段挂接脚本。
更多细节和案例请查看 脚本。
任意的，供 scripts 使用的额外数据。.
这可以是几乎任何东西。若要从脚本事件访问处理程序，你可以这样做：
$extra = $event->getComposer()->getPackage()->getExtra();可选。
该属性用于标注一组应被视为二进制脚本的文件，他们会被软链接到（config 对象中的）bin-dir 属性所标注的目录，以供其他依赖包调用。
详细请查看 Vendor Binaries。
可选。
这些选项在创建包存档时使用。
支持以下选项：
实例：
{ "archive": { "exclude": ["/foo/bar", "baz", "/*.test", "!/foo/bar/baz"] }}在这个例子中我们 include /dir/foo/bar/file、/foo/bar/baz、/file.php、/foo/my.test 但排除了 /foo/bar/any、/foo/baz、/my.test。
可选。