Composer命令行集锦及小案例 - 1

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

一个好消息，周五sf讲座 分析 composer.json文件各项，感兴趣的可以报名https://segmentfault.com/l/15...

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

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

about

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

init

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

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

我们看一下它的样子

你暂时无需在意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后，会发现一个警告信息，看下图。

上面图中警告出现的场景是我在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:UsersAdministratorAppDataLocalComposer（需要执行一次require才有会Composer目录），它的基本结构如下

切记，不要和全局目录混淆了，全局目录的位置为C:UsersAdministratorAppDataRoamingComposer，里面含有比如全局配置文件，全局安装的扩展包等。

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

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

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

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

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

composer clearcache

流程明白了吧，记住，这个clearcache也同时删除了C:UsersAdministratorAppDataLocal下的Composer文件夹自身。

archive

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

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

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

• 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/y... ,这个命令和另外一个home命令差不多。

composer home abei2017/yii2-emoji

小结

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

---