composer是现代PHP的基石
现代高级编程语言,依赖管理工具是必不可少的。Java有Maven,Python有pip,Nodejs有npm, 而在composer出现之前,PHP只有被广为诟病的Pear, 由于Pear实在太难用,很少PHP开发者用到这个工具。以致于PHP的开发生态很糟糕。
连一个像样的依赖管理工具都没有,让PHP这门占据了web网站开发主流市场的语言很尴尬。开发过程中,要用到第三方的类库,需要去下载zip包,然后解压,放到相应的目录,处理好命名空间,自动加载的问题,如果这个第三方包还有其他依赖项,还要再次重复这个流程,看着隔壁家python和node.js一个命令行就搞定,显得php开发人员的操作既原始又滑稽。
这场面,好比:
所幸,金光闪闪的composer驾着七彩祥云来了,PHP终于有了真正意义的依赖管理工具。可以说,composer是现代PHP的基石。
composer解决了项目的依赖关系,且实现了自动加载。开发人员只需要几个命令行,就能获取其他开发者的包,PHP开发工作因此变得如同堆积木,可以根据业务的需求,快速方便地拆解组合代码。
奇怪的是,即使compoer已经诞生好些年了,而且所有主流框架都支持composer,可竟然还有不少PHP开发者不用这个工具。甚至还有人觉得composer加大了PHP的学习难度。
持有这种想法的人,就好像是一辈子都用纸笔手工记账,有朝一日,给他配置了电脑,跟他演示了excel是如何地强大。他不为新事物的强大感到震撼惊喜,而是蹙眉不满地说:“这东西太难学了,我还是习惯用纸笔”。
对于持有这种想法的人,我只能两手一摊。心态衰老的年轻人,如果他的内心一直在装睡,任谁也叫不醒。但时代的步伐可不会因为他们的拉后腿而停止前进,只会把他们远远甩在身后...
安装流程
composer的安装步骤,在composr中文社区有详细的说明,点击查看
安装的流程很简单,归结为以下几步:
# 下载安装脚本 - composer-setup.php - 到当前目录
$ php -r "copy('https://install.phpcomposer.com/installer', 'composer-setup.php');"
# 执行安装过程
$ php composer-setup.php
# 删除安装脚本
$ php -r "unlink('composer-setup.php');"
# 全局安装
$ sudo mv composer.phar /usr/local/bin/composer
# 更换为阿里云镜像源
$ composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
第一次使用
接下来,我们用composer来安装第一个包
以 monolog
包为例,这个包可以让开发者很方便地将日记写入到文件、数据库或其他储存介质中。
- 在项目根目录新建
composer.json
文件,写入以下内容
{
"require": {
"monolog/monolog": "1.2.*"
}
}
- 执行
composer install
指令安装包依赖
- 使用包进行开发
composer已经为我们下载了 monolog
包,且生成了 autoload.php
自动加载文件
新建 monolog.php
文件,内容如下:
<?php
require 'vendor/autoload.php';
use Monolog\Logger;
use Monolog\Handler\StreamHandler;
// create a log channel
$log = new Logger('name');
$log->pushHandler(new StreamHandler('monolog.log', Logger::WARNING));
// add records to the log
$log->warn('警告日志');
$log->err('错误日志');
运行脚本:
$ php monolog.php
生成了日志文件 monolog.log
[2018-07-12 14:18:14] name.WARNING: 警告日志 [] []
[2018-07-12 14:18:14] name.ERROR: 错误日志 [] []
只需一个配置文件composer.json
,一行指令composer install
,代码中引入autoload.php
,即可完美地使用第三方包。接下来分析composer的包管理规范
composer包管理规范
什么是包?只要存在 composer.json
文件的代码都可以称之为一个包。
包名称
包名称由作者+项目名称组成。有些包作者名与项目名是相同的,如mustache/mustache
包名称一定要加上作者,避免冲突。如,同样的是小龙女这个角色,不同人演绎的效果完全不同。如果你只是说你要看小龙女,可能给你的是一个陈妍希版本的小笼包,而不是你一直仰慕的仙女刘亦菲。
那么,我们怎么根据一个包的项目名去获取包的信息呢?以mustache
包为例:
- 在packagist查找
点击进入包信息详情页,可以看到包的安装方法以及版本信息
除了在
composer.json
中写包的安装信息,还可以通过composer require mustache/mustache
这种方式直接安装
- 用
composer search
指令查找
查看包的具体信息 composer show mustache/mustache --all
包版本
在composer.json
中声明安装包时,需要指定包的版本,版本号的指定有多种格式:
- 确定的版本号
格式:1.0.2
最简单的指定方式,无歧义
- 在一定范围的版本号
可以定义多个范围,用逗号隔开,这将被视为一个逻辑AND处理。一个管道符号|将作为逻辑OR处理。 AND 的优先级高于 OR
>=1.0
: 大于或等于1.0版本
>=1.0,<2.0
: 大于或等于1.0,且小于2.0
>=1.0,<1.1|>=1.2
: 大于或等于1.0且等于1.1,或者大于等于1.2
- 通配符
1.0.*
: 只要满足以1.0开头的版本号均可
-
~
下一个重要版本
~1.2 相当于 >=1.2,<2.0
~1.2.3 相当于 >=1.2.3,<1.3
-
^
大于指定的版本
以下用实例演示版本号的区别: