Composer进阶使用 —— 经常使用命令和版本约束

这篇文章主要介绍一些经常使用的包管理命令以及包的版本如何进行约束。php

经常使用命令

require命令

在《Composer快速入门》中已经简单介绍过使用install命令安装依赖的方式。除了install命令,咱们还可使用require命令快速的安装一个依赖而不须要手动在composer.json里添加依赖信息:web

$ composer require monolog/monolog
Using version ^1.19 for monolog/monolog
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing psr/log (1.0.0)
    Downloading: 100%         

  - Installing monolog/monolog (1.19.0)
    Downloading: 100%         

monolog/monolog suggests installing graylog2/gelf-php (Allow sending log messages to a GrayLog2 server)
......
monolog/monolog suggests installing php-console/php-console (Allow sending log messages to Google Chrome)
Writing lock file
Generating autoload files

Composer会先找到合适的版本,而后更新composer.json文件,在require那添加monolog/monolog包的相关信息,再把相关的依赖下载下来进行安装,最后更新composer.lock文件并生成php的自动加载文件。json

update命令

经过update命令,能够更新项目里全部的包,或者指定的某些包。安全

# 更新全部依赖
$ composer update

# 更新指定的包
$ composer update monolog/monolog

# 更新指定的多个包
$ composer update monolog/monolog symfony/dependency-injection

# 还能够经过通配符匹配包
$ composer update monolog/monolog symfony/*

须要注意的时,包能升级的版本会受到版本约束的约束,包不会升级到超出约束的版本的范围。例如若是composer.json里包的版本约束为^1.10,而最新版本为2.0。那么update命令是不能把包升级到2.0版本的,只能最高升级到1.x版本。关于版本约束请看后面的介绍。bash

remove命令

使用remove命令能够移除一个包及其依赖(在依赖没有被其余包使用的状况下):composer

$ composer remove monolog/monolog
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Removing monolog/monolog (1.19.0)
  - Removing psr/log (1.0.0)
Writing lock file
Generating autoload files

search命令

使用search命令能够进行包的搜索:socket

$ composer search monolog
monolog/monolog Sends your logs to files, sockets, inboxes, databases and various web services

# 若是只是想匹配名称可使用--only-name选项
$ composer search --only-name monolog

show命令

使用show命令能够列出项目目前所安装的包的信息:ui

# 列出全部已经安装的包
$ composer show

# 能够经过通配符进行筛选
$ composer show monolog/*

# 显示具体某个包的信息
$ composer show monolog/monolog

版本约束

前面说到,咱们能够指定要下载的包的版本。例如咱们想要下载版本1.19的monolog。咱们能够经过composer.json文件:code

{
    "require": {
        "monolog/monolog": "1.19"
    }
}

而后运行install命令,或者经过require命令达到目的:orm

$ composer require monolog/monolog:1.19

# 或者
$ composer require monolog/monolog=1.19

# 或者
$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.12.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。它的值以下(按照稳定性排序):devalphabetaRCstable。除了修改这个配置去修改这个默认行为,咱们还能够经过稳定性标识(例如@stable@dev)来安装一个相比于默认配置不一样稳定性的版本。例如:

{
    "require": {
        "monolog/monolog": "1.0.*@beta",
        "acme/foo": "@dev"
    }
}

参考

相关文章
相关标签/搜索