直接说命令似乎很枯燥,咱就来个命令 + 图片,希望大家喜欢。

启动:命令行输入composer 或 composer -v既能看到命令列表,一共35个。

因为数量较多,分为3篇说完,本篇介绍其中的 about、init、install、update、clear-cache/clearcache、archive、browse\home 这9个。

about

这个命令实际意义不大,相当于composer的一句话简介吧,也不需要其他参数

init

顾名思义,初始化你的composer项目,再简单一点说就是向导的形式帮你生成一个composer.json,如果你喜欢手动创建composer.json也没有问题。

这个过程将你的项目也纳入了composer体系,composer.json里包含项目的基本信息(比如作者,项目名称等)和项目所需要的依赖(你vendor里的那些库),总之,通过init你新建了一个composer.json。

我们看一下它的样子

alt

你暂时无需在意composer.json里那些key-value,我们将在composer.json篇详细讲解。

install & update

重要且非常常用的命令,这两个命令需要放一起说才更好理解,install - 安装、update - 更新。说到这里,我们有必要顺一顺composer安装一个扩展的逻辑,认真看,这将是本篇最最重要的部分。

我们要先科普下两个文件,composer.json和composer.lock

  • composer.json记录项目及依赖信息
  • composer.lock记录项目及依赖当前版本信息

比如在composer.json有一条依赖是 "abei2017/yii2-emoji": "^1.0",那么你在composer.lock可以看到yii2-emoji当前用的是1.0.0版本,所以才有了下面的逻辑。

当我们composer install后,composer安装器进行了如下操作

  1. 如果当前目录下存在 composer.lock 文件,它会从此文件读取依赖版本,进行处理。
  2. 如果你当前项目没有 composer.lock 文件,它会从composer.json来读取依赖版本并更新到依赖最新版本,最后生成composer.lock

composer.lock 是一个标尺。

当然如果你手动修改了composer.json,然后执行composer install后,会发现一个警告信息,看下图。

alt

上面图中警告出现的场景是我在composer.json中改了项目的name值,然后composer install。这个警告是告诉我们Composer发现composer.json哈希值和composer.lock中记载的不同,因此不进行任何处理。

但是,但是,但是,我们如何在这个场景下保证json和lock文件一致那,其实也很简单,在我们改动了composer.json后执行如下命令

composer update nothing // 或composer update --lock

上面的命令不会处理依赖(有例外,如果改动了require数据,则会处理依赖),仅仅保证json和lock文件的一致。

要记住,install命令处理依赖的依据是composer.lock文件,比如一个image扩展当前最新版本是3.0,lock文件记录使用的是2.0,则install会按照2.0来安装,就像官方所说“composer.lock确保了一个项目组该库的每个使用者都能得到相同的依赖版本。”

接下来我们说说update,强大的update,永远追求最新版本的update。

update命令负责更新,从上面我们知道它能通过更新保证json和lock文件的一致,另外比如你在composer.json中修改了比如require(依赖)的增加或减少,执行 composer update也能直接帮你安装或删除相关依赖并保证json和lock文件的一致。

要记住的是 composer update 更新的是所有且更新到最新版本,如果要单独更新某个库,可以使用 composer update abei2017/yii2-emoji 。

update是一把利剑,它让很多人后悔莫已。

到此刻你会发现,install和update似乎都可以安装扩展,那么我们如何准确使用他们那?我们现在温习一下上面学习的结果,3条。

  • composer install 如有 composer.lock 文件,直接安装,否则从 composer.json 安装最新扩展包和依赖;
  • composer update 从 composer.json 安装最新扩展包和依赖;
  • composer update new/package - 添加安装 new/package, 可以指定版本,如: composer update new/package ~3.5.

所以一般我们如下部署程序

  1. 创建 composer.json,并添加依赖到的扩展包;
  2. 运行 composer install,安装扩展包并生成 composer.lock;
  3. 提交 composer.lock 到代码版本中;
  4. 克隆项目到生产环境,根目录下直接运行 composer install 从 composer.lock 中安装指定版本的扩展包以及其依赖;

一句话就是保证composer.lock的一致和稳定。其实最稳定安装扩展的方法是requrie命令(下篇讲到)。

另外上面是在思路方面为大家介绍install 和 update,这两个命令还有很多参数,刚阿北看了下到很好了解,这里列出来不一一讲解,有不懂留言即可。

install

  • --prefer-source: 下载包的方式有两种: source 和 dist。对于稳定版本 composer 将默认使用 dist 方式。而 source 表示版本控制源 。如果 --prefer-source 是被启用的,composer 将从 source 安装(如果有的话)。如果想要使用一个 bugfix 到你的项目,这是非常有用的。并且可以直接从本地的版本库直接获取依赖关系。
  • --prefer-dist: 与 --prefer-source 相反,composer 将尽可能的从 dist 获取,这将大幅度的加快在 build servers 上的安装。这也是一个回避 git 问题的途径,如果你不清楚如何正确的设置。
  • --dry-run: 如果你只是想演示而并非实际安装一个包,你可以运行 --dry-run 命令,它将模拟安装并显示将会发生什么。
  • --dev: 安装 require-dev 字段中列出的包(这是一个默认值)。
  • --no-dev: 跳过 require-dev 字段中列出的包。
  • --no-scripts: 跳过 composer.json 文件中定义的脚本。
  • --no-plugins: 关闭 plugins。
  • --no-progress: 移除进度信息,这可以避免一些不处理换行的终端或脚本出现混乱的显示。
  • --optimize-autoloader (-o): 转换 PSR-0/4 autoloading 到 classmap 可以获得更快的加载支持。特别是在生产环境下建议这么做,但由于运行需要一些时间,因此并没有作为默认值。

update

  • --prefer-source: 当有可用的包时,从 source 安装。
  • --prefer-dist: 当有可用的包时,从 dist 安装。
  • --dry-run: 模拟命令,并没有做实际的操作。
  • --dev: 安装 require-dev 字段中列出的包(这是一个默认值)。
  • --no-dev: 跳过 require-dev 字段中列出的包。
  • --no-scripts: 跳过 composer.json 文件中定义的脚本。
  • --no-plugins: 关闭 plugins。
  • --no-progress: 移除进度信息,这可以避免一些不处理换行的终端或脚本出现混乱的显示。
  • --optimize-autoloader (-o): 转换 PSR-0/4 autoloading 到 classmap 可以获得更快的加载支持。特别是在生产环境下建议这么做,但由于运行需要一些时间,因此并没有作为默认值。
  • --lock: 仅更新 lock 文件的 hash,取消有关 lock 文件过时的警告。
  • --with-dependencies 同时更新白名单内包的依赖关系,这将进行递归更新。

clear-cache & clearcache

这个要说下,和名字一样,清空所有缓存,我们来顺一顺。

当我们使用require安装一个扩展的时候,composer会在我们机器上留一个缓存文件夹,一般是在 C:\Users\Administrator\AppData\Local\Composer(需要执行一次require才有会Composer目录),它的基本结构如下

缓存文件夹

切记,不要和全局目录混淆了,全局目录的位置为C:\Users\Administrator\AppData\Roaming\Composer,里面含有比如全局配置文件,全局安装的扩展包等。

下面我们来看一下这个过程,首先我requrie了一个扩展包,如下图 alt

如图所示,这个过程是从服务器下载的,然后我们看看缓存文件夹

alt

看到了吧,此刻在缓存文件夹的files子文件夹里多了一个abei2017/yii2-emoji/xxx.zip的文件,这个就是缓存,接下来我们删除项目的yii2-emoji然后再安装,看看有何不同了,看下图

从缓存读取 不一样了吧,下一次从缓存读取,你是否发现速度快了很多,那是必须的。

所以,有些问题你可以清空缓存试试,比如版本问题等等。好了,我们还没有说clear-cache命令那(clearcache一个意思)

composer clearcache

alt

流程明白了吧,记住,这个clearcache也同时删除了C:\Users\Administrator\AppData\Local\下的Composer文件夹自身。

archive

首先要知道这仍然是一个从远程下载的过程,只不过下载后将其打包成了zip/tar压缩包,比如你可以打包某个扩展发给你的同事等。官方手册的书写方法会让一些初学者误会 对于包的指定是不能含有vendor的,接下来的命令是正确的

composer archive abei2017/yii2-emoji --format=zip --dir ./zip

结果如下图,我们一一说明下。

archive

  • 1 如果要指定版本,后面空格然后直接放版本号就可以,不指定也没事,会自动选择稳定最新的。
  • 2 两种格式,不写则默认是tar,推荐使用zip。
  • 3 如果不指定就在当前项目的根目录,你可以指定当前项目的相对路径,比如 ./zip,composer如果发现无此目录会自己建立,当然你也可以指定比如 D:\zip,一个绝对的路径。
  • 4 从4中你应该看到,这仍然是一个install的过程,不过你不用担心,虽然是install,但是它并没有对你的vendor进行写入,仅仅是生成了归档文件而已。

要注意:运行此命令生成归档文件并不会下载此扩展相关的依赖。

browse && home

浏览,这个命令我觉得最大的一个用处就是打开仓库页面、比如我输入了

composer browse abei2017/yii2-emoji

命令行会调出浏览器并打开 https://github.com/abei2017/yii2-emoji.git ,这个命令和另外一个home命令差不多。

composer home abei2017/yii2-emoji

小结

本篇就说这些,其中update在后面还有讲,尤其是介绍requrie命令时候要和它有一些对比,也帮大家分析出当我们安装或升级一个扩展的时候,正确姿势为何用require而不是update。