Composer是一款应用于PHP的免费且专业的依赖关系管理工具，不但能够帮助用户在自己的项目中声明所依赖的外部工具库，而且还能够帮助你安装这些依赖的库文件，并且Composer默认情况下不会在全局安装任何东西，让你放心使用。

Composer是PHP专门用来管理依赖关系的出色软件，这款软件能够找出哪个版本的包需要安装，并开始将它们下载到你的项目中，而且它还能够在每个项目的基础上进行管理，是极为优质的依赖管理软件。

Composer功能

1、你有一个项目依赖于假如干个库。

2、其中一些库依赖于其他库。

3、你声明你所依赖的东西。

4、Composer 会找出哪个版本的包需要安装，并安装它们《将它们下载到你的项目中》。

镜像用法

有两种方式启用本镜像服务：

系统全局配置： 即将配置信息添加到 Composer 的全局配置文件 config.json 中。见“方法一”

单个项目配置： 将配置信息添加到某个项目的 composer.json 文件中。见“方法二”

方法一： 修改 composer 的全局配置文件（推荐方式）

打开命令行窗口（windows用户）或控制台（Linux、Mac 用户）并执行如下命令：

composer config -g repo.packagist composer https://packagist.phpcomposer.com

方法二： 修改当前项目的 composer.json 配置文件：

打开命令行窗口（windows用户）或控制台（Linux、Mac 用户），进入你的项目的根目录（也就是 composer.json 文件所在目录），执行如下命令：

composer config repo.packagist composer https://packagist.phpcomposer.com

上述命令将会在当前项目中的 composer.json 文件的末尾自动添加镜像的配置信息（你也可以自己手工添加）：

"repositories": {

"packagist": {

"type": "composer",

"url": "https://packagist.phpcomposer.com"

}

}

以 laravel 项目的 composer.json 配置文件为例，执行上述命令后如下所示（注意最后几行）：

{

"name": "laravel/laravel",

"description": "The Laravel Framework.",

"keywords": ["framework", "laravel"],

"license": "MIT",

"type": "project",

"require": {

"php": ">=5.5.9",

"laravel/framework": "5.2.*"

},

"config": {

"preferred-install": "dist"

},

"repositories": {

"packagist": {

"type": "composer",

"url": "https://packagist.phpcomposer.com"

}

}

}

OK，一切搞定！试一下 composer install 来体验飞一般的速度吧！

常见问题

一、为什么 Composer 不递归加载储存库？

当你使用自定义库时，你可能会碰到问题，因为 Composer 不会递归加载你要求的储存库，所以你必须修改这些储存库中所有的 composer.json 文件。

在详细说明为什么是这样之前，你需要明白：使用自定义 VCS & 包储存库去尝试某些事情，或者使用你 fork 的一个分支，直到你的 pull request 被合并，等等。你不应该使用它们来跟踪你的私人资源包，关于这点你应该看看 setting up Satis 来为你的公司甚至自己处理私人资源包。

这里有三个途径可以使依赖解析器使用你自定义的储存库：

1、读取根包的存储库，从定义的存储库得到所有的软件包，解析依赖需求。这是目前的状态，它工作得很好，除了有“无法递归的加载储存库”这个限制。

2、读取根包的存储库，同时从定义的 repos 初始化资源包，递归的初始化，根据所有依赖包中定义的 repos，以及这些依赖包所依赖的其它包中定义的 repos，等等，然后再解析依赖需求。这可能可以工作，但会严重影响初始化的速度，因为每读取一个 VCS repos 都需要几秒钟。它可能最终执行失败，因为一个包的不同版本，可能来自一个包资源库中一个相同的包，但来至不同的 dist/source 。这样有太多的可能会出错。

3、读取根包的存储库，然后读取第一级依赖，接着读取这些依赖包所依赖的其它包，等等，然后再解析依赖需求。这样听起来更有效率，但仍然存在第二种解决方案中的问题。因为加载依赖的储存库并不像听起来那么容易。你需要加载所有可能匹配的依赖包的 repos，而这些包的定义又可能是互相冲突的。

二、我应该提交 vendor 目录中的依赖包吗？

一般情况下 不建议。vendor 目录（或者你安装依赖的其它目录）都应该被添加进 .gitignore/svn:ignore/等等。

最好这么做，然后让所有开发人员使用 Composer 来安装依赖包。同样，build server、CI、deployment tools 等等，应进行修改，使运行 Composer 成为其项目引导的一部分。

虽然在某些环境下提交它是很让人心动的，但它将导致一些问题：

1、当你更新代码时，将极大的增加 VCS 仓库的体积和差异。

2、在你自己的 VCS 中将产生与你依赖的资源包重复的历史记录。

3、通过 git 的一个 git 仓库安装添加依赖，将把它们视作子模块。这是有问题的，因为它们并不是真正的子模块，并且你将会遇到这些问题。

如果你真的觉得你必须这样做，你有几个选择：

1、限制自己安装标记版本（无 dev 版本），这样你只会得到 zip 压缩的安装，并避免 git“子模块”出现的问题。

2、使用 --prefer-dist 或在 config 选项中设置 preferred-install 为 dist。

3、在每一个依赖安装后删除其下的 .git 文件夹，然后你就可以添加它们到你的 git repo 中。你可以运行 rm -rf vendor/**/.git 命令快捷的操作，但这意味着你在运行 composer update 命令前需要先删除磁盘中的依赖文件。

4、新增一个 .gitignore 规则（vendor/.git）来忽略 vendor 下所有 .git 目录。这种方法不需要你在运行 composer update 命令前删除你磁盘中的依赖文件。