PHP7 学习笔记（十三）composer详解一

摘要

　　从拷贝第三方代码到项目中(1994)，到PEAR安装依赖包(1999)，再到Composer兴起(2012)，PHP社区经历了将近20年的探索。PHP这门古老的语言，也在不断的发展更新，在web领域一直发光发热。Composer做为目前PHP包依赖管理的最佳工具，值得每一位PHP开发人员掌握。

官网

　　https://www.phpcomposer.com/

什么是composer？

　　是 PHP 用来管理依赖（dependency）关系的工具。你能够在本身的项目中声明所依赖的外部工具库（libraries），Composer 会帮你安装这些依赖的库文件。

拓展和包

一、拓展和包是两个很是相近的概念。在PHP世界里，通常能够这样理解和区分二者：拓展（extension）和模块（module）等价，是用C语言写的功能合集。

二、包(package)和库（library）等价，主要是用PHP实现的功能合集；拓展以动态连接库（.dll或.so）的形式加载，包则是经过require/include方式加载。绝大部分时候，二者混用不会形成理解上的困难。

三、常见的拓展：GD、ZIP、XML、MySQLi、OPCache等。

四、常见的包：PHPMailer、PHPOffice、HTMLPurifier等。

PEAR和PECL

　　在Composer流行以前，PEAR和PECL是更为PHP开发者所知的两个工具（社区）。PEAR是PHP拓展和应用仓库（PHP Extension and Application Repository）的缩写，官网http://pear.php.net；PECL是PHP拓展社区库（PHP Extension Community Library）的缩写，官网http://pecl.php.net。

　　二者的区别可用拓展和包来区分：PECL托管拓展，源代码多为C文件，例如APC、AMPQ等；PEAR托管包，功能用PHP实现，如PHP CodeSniffer、HTTP Request等；PEAR对应pear命令，PECL对应pecl命令，可用这两个命令安装和管理拓展和包（pear的build/pickle子命令也能够编译PECL中的拓展）。二者互为补充，官网以姐妹（sisters）形容二者的关系。

　　PECL是官方拓展的补充，目前仍处于活跃状态，一些优秀的拓展有成为官方拓展的潜质。韩天峰大神的swoole拓展也托管在PECL中，国内名气很是高。相比之下PEAR已经是明日黄花。PEAR2和Pyrus（下一代的PEAR包安装工具，基于PHP5.3+构建，官网http://pear2.php.net）的出现也未能挽救PEAR。PEAR没落伴随着本文主角Composer的兴起。

　　PEAR的定位是“提供可复用的PHP组件”，以中心化的方式为开发者提供功能包。中心化发布的方式保证了代码的质量，同时带来维护上的不便：经过评审的包才能发布，包过期现象严重。PEAR安装的包是全局的，不能为单独项目安装依赖包，非特权用户不能自行安装依赖包。其余缺点还包括糟糕的依赖管理。随着Github的流行和Composer的出现，包管理进入Composer时代。PEAR已经完成其历史使命，能够安心的去了。

Composer

严格来讲，Composer的定位是依赖管理工具而非包管理器。Composer中文网对Composer工做介绍以下。Composer 将这样为你解决问题：

a) 你有一个项目依赖于若干个库。

b) 其中一些库依赖于其余库。

c) 你声明你所依赖的东西。

d) Composer 会找出哪一个版本的包须要安装，并安装它们（将它们下载到你的项目中）。

　　PEAR能作的事情，Composer都能作（包括安装PECL拓展），部分还能作得更好。Composer默认把包安装在项目目录下，普通用户就能正常使用（Composer官方建议不要以root身份执行composer命令）；鼓励遵循最佳实践（即大名鼎鼎的PSR规范，详情见PHP-FIG官网https://www.php-fig.org），极大的推进PHP社区编码风格的规范化；Composer是去中心化的平台，任何人都可发布代码包；发布包无需评审，包的质量由用户投票决定...做为PEAR的继任者，Composer的表现经受住了社区的考验，并成为事实上的依赖管理标准工具。

　　Composer目前已经造成庞大的生态，在数量上，Composer的包远超PEAR。因为任何人都可自由发布包且无需评审，Composer生态中的包可能存在代码质量良莠不齐、代码风格各异、后门漏洞等隐忧。另外Composer的依赖管理以项目为单位，一台机器上可能屡次安装同一个包。但瑕不掩瑜，整体而言，Composer极大的改变了PHP的开发生态，促进了代码交流和社区发展。

Composer用法

Composer为管理的项目的依赖而生，项目中的composer.json文件是其工做的依据。该文件中最重要的部分是require部分，该部分告诉Composer指望安装的包及其版本，例如：

{
    "name": "tinywan/easy-live",
    "description": "nginx live module",
    "type": "library",
    "license": "MIT",
    "authors": [
        {
            "name": "Tinywan",
            "email": "756684177@qq.com"
        }
    ],
    "require": {
        "php": ">=7.0"
    },
    "autoload": {
        "psr-4": {
            "live\\": "src"
        }
    }
}

　　而后运行 composer install 命令，Composer会自动分析依赖，安装最合适的包到vendor目录下。加-v(-vv, -vvv)选项会打印命令执行过程当中的详细信息。安装完毕后，vendor目录下会生成autoload.php文件。在项目的入口文件中包含此文件： require __DIR__ . "/vendor/autoload.php";，接下来即可在项目的任何地方引用依赖包中的接口和类。

除install命令，Composer提供了许多其余命令管理依赖。经常使用的命令场景包括：查找依赖、引入依赖、安装依赖、更新依赖。分别对应的命令是：

 

　　一、composer search: 根据关键字查找依赖包，例如查找本人发布的包：composer search live。该命令等同于上https://packagist.org进行包查找；

 

　　二、composer require: 引入依赖，声明项目或者全局(global，用户名全局，非系统全局)依赖某个包， 例如声明须要swiftmailer包： composer require [global] "swiftmailer/swiftmailer:dev-master"；该命令更新composer.json文件，并默认当即安装依赖（--no-update选项可阻止默认安装）；效果等同于编辑composer.json文件，而后执行install命令；

 

　　三、composer install：安装composer.json声明的依赖包，最终安装的依赖包版本可能取决于有无composer.lock文件；

 

　　四、composer update： 更新依赖到最新版本，至关于删除composer.lock文件后执行composer install。

 

以上四条命令涵盖使用Composer的大部分场景。如下是几个经常使用的辅助命令，与依赖分析相关：

　　一、composer info： 查看安装的依赖包信息，与composer show等价；

　　二、composer dumpautoload： 加-o选项可导出优化的加载器；

　　三、composer why(-not)： 查看（不）安装某个包的缘由。

总结

。。。

参考

一、https://my.oschina.net/u/1030865/blog/1788303

二、https://benramsey.com/blog/2013/11/the-fall-of-pear-and-the-rise-of-composer/

三、http://fabien.potencier.org/the-rise-of-composer-and-the-fall-of-pear.html

四、http://docs.phpcomposer.com/