这一次,真正掌握composer

composer是现代PHP的基石

转自:https://www.itshutong.com/337.html

现代高级编程语言,依赖管理工具是必不可少的。Java有Maven,Python有pip,Nodejs有npm, 而在composer出现之前,PHP只有被广为诟病的Pear, 由于Pear实在太难用,很少PHP开发者用到这个工具。以致于PHP的开发生态很糟糕。

连一个像样的依赖管理工具都没有,让PHP这门占据了web网站开发主流市场的语言很尴尬。开发过程中,要用到第三方的类库,需要去下载zip包,然后解压,放到相应的目录,处理好命名空间,自动加载的问题,如果这个第三方包还有其他依赖项,还要再次重复这个流程,看着隔壁家python和node.js一个命令行就搞定,显得php开发人员的操作既原始又滑稽。

这场面,好比:

 

这一次,真正掌握composer_第1张图片

 

所幸,金光闪闪的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 镜像源

第一次使用

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

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

  1. 在项目根目录新建 composer.json 文件,写入以下内容
{
    "require": {
        "monolog/monolog": "1.2.*"
    }
}
  1. 执行 composer install 指令安装包依赖

 

这一次,真正掌握composer_第2张图片

 

  1. 使用包进行开发

 

这一次,真正掌握composer_第3张图片

 

composer已经为我们下载了 monolog 包,且生成了 autoload.php 自动加载文件

新建 monolog.php 文件,内容如下:

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包为例:

  1. 在packagist查找

 

这一次,真正掌握composer_第4张图片

 

点击进入包信息详情页,可以看到包的安装方法以及版本信息

 

这一次,真正掌握composer_第5张图片

 

除了在composer.json中写包的安装信息,还可以通过composer require mustache/mustache这种方式直接安装

 

这一次,真正掌握composer_第6张图片

 

  1. composer search指令查找

 

这一次,真正掌握composer_第7张图片

 

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

 

这一次,真正掌握composer_第8张图片

 

包版本

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

 

这一次,真正掌握composer_第9张图片

 

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

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

 

这一次,真正掌握composer_第10张图片

 

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

 

这一次,真正掌握composer_第11张图片

 

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

 

这一次,真正掌握composer_第12张图片

 

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

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

 

这一次,真正掌握composer_第13张图片

 

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

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项目为例:

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

 

这一次,真正掌握composer_第14张图片

 

开发与生产环境分开

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

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

 

这一次,真正掌握composer_第15张图片

 

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

 

这一次,真正掌握composer_第16张图片

 

自定义脚本

在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时的相应阶段,会自动触发运行脚本

 

这一次,真正掌握composer_第17张图片

 

发布自己的包

  1. github是新建一个仓库

 

这一次,真正掌握composer_第18张图片

 

  1. 创建composer.json文件

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

 

这一次,真正掌握composer_第19张图片

 

  1. 在packagist提交github仓库地址

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

提交github仓库地址

 

这一次,真正掌握composer_第20张图片

 

包创建成功

 

这一次,真正掌握composer_第21张图片

 

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

  1. 设置自动同步

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

在github中添加packagist服务

 

这一次,真正掌握composer_第22张图片

 

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

 

这一次,真正掌握composer_第23张图片

 

提交配置

 

这一次,真正掌握composer_第24张图片

 

结语

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

你可能感兴趣的:(PHP技术扩充)