Composer 进阶使用之常用命令和版本约束
这篇文章主要介绍一些常用的包管理命令以及包的版本如何进行约束。
常用命令
require 命令
在《Composer 快速入门》中已经简单介绍过使用 install
命令安装依赖的方式。除了 install
命令,我们还可以使用 require
命令快速的安装一个依赖而不需要手动在 composer.json
里添加依赖信息:
1 |
$ composer require monolog/monolog |
Composer 会先找到合适的版本,然后更新 composer.json
文件,在 require
那添加 monolog/monolog
包的相关信息,再把相关的依赖下载下来进行安装,最后更新 composer.lock
文件并生成 php 的自动加载文件。
update 命令
通过 update
命令,可以更新项目里所有的包,或者指定的某些包。
1 |
# 更新所有依赖 |
需要注意的时,包能升级的版本会受到版本约束的约束,包不会升级到超出约束的版本的范围。例如如果 composer.json
里包的版本约束为 ^1.10
,而最新版本为 2.0。那么 update
命令是不能把包升级到 2.0 版本的,只能最高升级到 1.x 版本。关于版本约束请看后面的介绍。
remove 命令
使用 remove 命令可以移除一个包及其依赖(在依赖没有被其他包使用的情况下):
1 |
$ composer remove monolog/monolog |
search 命令
使用 search
命令可以进行包的搜索:
1 |
$ composer search monolog |
show 命令
使用 show
命令可以列出项目目前所安装的包的信息:
1 |
# 列出所有已经安装的包 |
以上是常用命令的介绍。
版本约束
前面说到,我们可以指定要下载的包的版本。例如我们想要下载版本 1.19 的 monolog。我们可以通过 composer.json
文件:
1 |
{ |
然后运行 install
命令,或者通过 require
命令达到目的:
1 |
$ composer require monolog/monolog:1.19 |
除了像上面那样指定具体的版本,我们还可以通过不同的约束方式去指定版本。
基本约束
精确版本
可以指定具体的版本,告诉 Composer 只能安装这个版本。但是如果其他的依赖需要用到其他的版本,则包的安装或者更新最后会失败并终止。 例子:1.0.2
范围
使用比较操作符你可以指定包的范围。这些操作符包括:\>
,\>=
,<
,<=
,!=
。 你可以定义多个范围,使用空格 或者逗号 ,
表示逻辑上的与,使用双竖线 ||
表示逻辑上的或。其中与的优先级会大于或。
需要注意的是,使用没有边界的范围有可能会导致安装不可预知的版本,并破坏向下的兼容性。建议使用折音号操作符。
例子:
\>=1.0
\>=1.0 <2.0
\>=1.0 <1.1 || >=1.2
范围(使用连字符)
带连字符的范围表明了包含的版本范围,意味着肯定是有边界的。其中连字符的左边表明了 \>=
的版本,而连字符的右边情况则稍微有点复杂。如果右边的版本不是完整的版本号,则会被使用通配符进行补全。例如 1.0 - 2.0
等同于 \>=1.0.0 <2.1
(2.0
相当于 2.0.*
),而 1.0.0 - 2.1.0
则等同于 \>=1.0.0 <=2.1.0
。 例子:1.0 - 2.0
通配符
可以使用通配符去定义版本。1.0.*
相当于 \>=1.0 <1.1
。 例子:1.0.*
下一个重要版本操作符
波浪号 ~
我们先通过后面这个例子去解释 ~
操作符的用法:~1.2
相当于 \>=1.2 <2.0.0
,而 ~1.2.3
相当于 \>=1.2.3 <1.3.0
。对于使用 Semantic Versioning 作为版本号标准的项目来说,这种版本约束方式很实用。例如 ~1.2
定义了最小的小版本号,然后你可以升级 2.0 以下的任何版本而不会出问题,因为按照 Semantic Versioning 的版本定义,小版本的升级不应该有兼容性的问题。简单来说,~
定义了最小的版本,并且允许版本的最后一位版本号进行升级(没懂得话,请再看一边前面的例子)。 例子:~1.2
需要注意的是,如果
~
作用在主版本号上,例如~1
,按照上面的说法,Composer 可以安装版本 1 以后的主版本,但是事实上是~1
会被当作~1.0
对待,只能增加小版本,不能增加主版本。
折音号 ^
^
操作符的行为跟 Semantic Versioning 有比较大的关联,它允许升级版本到安全的版本。例如,^1.2.3
相当于 \>=1.2.3 <2.0.0
,因为在 2.0 版本前的版本应该都没有兼容性的问题。而对于 1.0 之前的版本,这种约束方式也考虑到了安全问题,例如 ^0.3
会被当作 \>=0.3.0 <0.4.0
对待。 例子:^1.2.3
版本稳定性
如果你没有显式的指定版本的稳定性,Composer 会根据使用的操作符,默认在内部指定为 \-dev
或者 \-stable
。例如:
约束
内部约束
1.2.3
\=1.2.3.0-stable
>1.2
>1.2.0.0-stable
>=1.2
>=1.2.0.0-dev
>=1.2-stable
>=1.2.0.0-stable
<1.3
<1.3.0.0-dev
<=1.3
<=1.3.0.0-stable
1 - 2
>=1.0.0.0-dev <3.0.0.0-dev
~1.3
>=1.3.0.0-dev <2.0.0.0-dev
1.4.*
>=1.4.0.0-dev <1.5.0.0-dev
如果你想指定版本只要稳定版本,你可以在版本后面添加后缀 \-stable
。 minimum-stability
配置项定义了包在选择版本时对稳定性的选择的默认行为。默认是 stable
。它的值如下(按照稳定性排序):dev
,alpha
,beta
,RC
和 stable
。除了修改这个配置去修改这个默认行为,我们还可以通过稳定性标识(例如 @stable
和 @dev
)来安装一个相比于默认配置不同稳定性的版本。例如:
1 |
{ |
以上是版本约束的介绍
参考
- https://segmentfault.com/a/1190000005898222
- https://getcomposer.org/doc/03-cli.md[2]
- https://getcomposer.org/doc/articles/versions.md[3]
- http://semver.org/[1]
文章来源: cuiqingcai.com,作者:崔庆才,版权归原作者所有,如需转载,请联系作者。
原文链接:cuiqingcai.com/3494.html
- 点赞
- 收藏
- 关注作者
评论(0)