这一次，真正掌握composer

法律可以给正义公正吗 · 发表于 2019-5-27 11:37:00

思维导图

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

composer的安装步骤，在composr中文社区有详细的说明，点击查看

安装流程

安装的流程很简单，归结为以下几步：

php -r "copy('https://install.phpcomposer.com/installer', 'composer-setup.php');" # 下载安装脚本 － 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://packagist.phpcomposer.com # 更换国内镜像源

安装完成后，查看composer版本

composer

第一次使用

接下来，我们用composer来安装第一个包

以monolog包为例，这个包可以让开发者很方便地将日记写入到文件、数据库或其他储存介质中。

在项目根目录新建composer.json文件，写入以下内容

{
    "require": {
        "monolog/monolog": "1.2.*"
    }
}

执行composer install指令安装包依赖

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('错误日志');

运行脚本：

  learnComposer  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 search

查看包的具体信息 composer show mustache/mustache --all

composer show

包版本

在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

^大于指定的版本

以下用实例演示版本号的区别：

清空根目录，composer.json内容为：

{
"require": {
"mustache/mustache": "2.6.0"
}
}

执行composer install

指定版本

接下来，删除vendor目录，将版本号改为~2.6.0, 执行composer install

此时，会发现版本号并没有变化

composer install 无效

这是因为当我们第一次执行composer install，会生成composer.lock文件，这个文件记录了包的指定版本

版本锁定

当我们再次执行composer install时，�composer会先去composer.lock中检查有没有相应的包信息，如果有，以composer.lock的版本为准。如果我们要跳过composer.lock的限制，需要改用composer update指令

composer update

此时，我们看到，版本已经更新为2.6.1

最后再试下将版本号改为^2.6.0, 执行composer update

版本更新

此时，已经更新到最新版本号

`composer.lock`锁文件

composer.json在指定版本时，不一定是精确指定，很多时候是使用范围指定，只有当我们安装了包，才知道最终安装了哪个版本。那么问题来了，如果我们半年后再根据composer.json来安装包，可能有些包的版本已经升级了，且向下不兼容，这就有可能导致程序报错。为避免这种问题，在执行composer install之后，composer会生成composer.lock锁文件。

在锁文件中可以看到完整的包信息，包括包的版本号。

composer install命令会先检查锁文件是否存在，如果存在，它将下载composer.lock指定的版本（忽略 composer.json 文件中的定义）

如果在composer.json中修改了版本号，必须执行composer update命令，这个命令会根据composer.json的定义安装包，并更新composer.lock文件

锁文件非常重要！必须将composer.lock文件上传到代码仓库，这样才能保证团队各成员所安装的包版本是一致的。

创建项目

composer通过create-project 可以直接创建一个完整的项目，将包所在的代码仓库clone下来

以创建laravel项目为例：

  learnComposer  composer create-project laravel/laravel Laravel --prefer-dist "5.5.*"

create-project

开发与生产环境分开

有些包我们仅需要在本地安装，生产环境并不需要，可以在composer.json中通过require-dev进行声明，如：

composer install --no-dev 会忽略require-dev所声明的包

�--no-dev

composer install会将require-dev声明的包一并获取

install

自定义脚本

在Laravel的composer.json文件中，有这么一段声明：

"scripts": {
"post-root-package-install": [
"@php -r \"file_exists('.env') || copy('.env.example', '.env');\""
],
"post-create-project-cmd": [
"@php artisan key:generate"
],
"post-autoload-dump": [
"Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
"@php artisan package:discover"
]
},

表示在执行composer install时的相应阶段，会自动触发运行脚本

触发脚本

发布自己的包

github是新建一个仓库

github仓库

创建composer.json文件

在项目根目录执行composer init，生成composer.json配置文件

composer init

在packagist提交github仓库地址

在packagist注册账号，然后登录。

提交github仓库地址

submit

包创建成功

创建成功

如果用的是国内的镜像，暂时还不能拉取，需要等国内镜像同步成功后才能拉取

设置自动同步

如果要实现当github仓库代码更新就触发包的自动更新，需要进行以下设置

在github中添加packagist服务

add service

自动同步需要用到packagist的Api token，查看token

show profile

提交配置

active server

结语

掌握以上的composer基础操作，在日常开发中已经足够使用。如果你是一个没怎么用过composer的php开发者，强烈推荐你从现在开始就用composer。在我看来，composer不仅仅是一个工具，而是联结php应用的生态，如果没有composer或类似的依赖管理工具，很难想象PHP还能保持活力。