PHP使用Composer安装第三方包库

发表于 | 分类于

配置文件composer.json

Composer的配置文件为项目根目录下的composer.json文件，对第三方库的依赖就配置在此文件中：在require或者require-dev中填入相应的库的名称以及版本需求。

1
2
3
4
5
6
7
8
9
{                             
    "require" : {             
        "php": ">5.3.0",      
        "curl/curl": ">=1.4.0"
    },                        
    "require-dev": {          
        "phpunit/phpunit": "*"
    }
}

安装依赖库到本地

composer install

在composer.json文件所在目录执行composer install, composer.json里填写的依赖包就会被下载到本地。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
0 composer-learn $ ls
composer.json
0 composer-learn $ composer install
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing curl/curl (1.4.0)
    Loading from cache
    ......
    many package...
    ......
Writing lock file
Generating autoload files
0 composer-learn $ ls
composer.json  composer.lock  vendor/
0 composer-learn $ ls vendor/
autoload.php  composer/  doctrine/  phpdocumentor/  phpunit/    symfony/
bin/          curl/      myclabs/   phpspec/        sebastian/  webmozart/

  1. 如果没有composer.lock文件的话，composer install命令就会从composer.json文件中读取依赖关系，并根据composer.json中的配置生成composer.lock文件。注意上面示例中输出的：Writing lock file
  2. 如果当前目录中有composer.lock文件的话: composer install命令将会从lock文件中读取对应的依赖信息；

composer update

如果新增或修改了composer.json里的包的依赖信息，改怎么办呢？

  1. 删除composer.lock文件，重新执行composer install命令，当然这看起来有点蠢。
  2. 执行composer update命令。composer update会从composer.json中重新获取依赖关系，并将新的信息更新到composer.lock文件中。

require和require-dev的区别

通过操作你可以看到，文件中require和require-dev段的配置都会被安装到本地，那么require和require-dev有什么差异呢？

字面意义区别

require: 代码中必须要用到的库。
require-dev: 开发环境需要，但在正式环境中不要的库。比如用于单元测试的phpunit/phpunit。

Composer是如何判断是否开发环境的？

Composer本身是无法判断当前环境是正式环境还是开发环境的，需要我们通过参数的方式告诉composer到底需要什么方式的安装。

  • 如我们所见，require和require-dev段的配置默认都会被安装。在老版本的composer中，require-dev的配置默认是不会安装的，需要使用composer install --dev的方式来安装require-dev中的依赖包。
  • 在生产环境机器上，我们不想安装phpunit等不需要的包，可以通过composer install --no-dev命令进行安装。如果已经安装了require-dev中的依赖包，执行此命令将会删除已安装的require-dev的包。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    0 composer-learn $ ls
    composer.json  composer.lock  vendor/
    0 composer-learn $ composer install --no-dev
    Loading composer repositories with package information
    Installing dependencies from lock file
      - Removing phpunit/phpunit (5.6.1)
      - Removing myclabs/deep-copy (1.5.4)
      ...
      - Removing symfony/yaml (v3.1.5)
    Generating autoload files
    0 composer-learn $ ls vendor/
    autoload.php  bin/  composer/  curl/

如何改变包安装的目录

第三方包默认安装到composer所在目录下的vendor文件夹下。如果想要改变依赖包的路径，可以通过修改配置vendor-dir的值来更改。

1
2
3
4
5
6
7
8
9
10
11
12
{
    "config": {
        "vendor-dir": "folder/plugins"
    },
    "require" : {
        "php": ">5.3.0",
        "curl/curl": ">=1.4.0"
    },
    "require-dev": {
        "phpunit/phpunit": "*"
    }
}

执行安装命令进行测试：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
0 composer-learn $ ls                                   
composer.json                                           
0 composer-learn $ composer install --no-dev            
Loading composer repositories with package information  
Updating dependencies                                   
  - Installing curl/curl (1.4.0)                        
    Loading from cache                                  

Writing lock file                                       
Generating autoload files                               
0 composer-learn $ ls                                   
3rdParty/  composer.json  composer.lock                 
0 composer-learn $ ls 3rdParty/vendor/                  
autoload.php  composer/  curl/

依赖包的版本

版本约束可以通过以下几种方法指定。

名称 示例 描述
确切的版本号 1.0.2 你可以指定包的确切版本。
范围 >=1.0 >=1.0,<2.0
>=1.0,<1.1 |="">=1.2		 通过使用比较操作符可以指定有效的版本范围。
有效的运算符：>、>=、<、<=、!=。
你可以定义多个范围，用逗号隔开，这将被视为一个逻辑AND处理。
一个管道符号|将作为逻辑OR处理。 AND 的优先级高于 OR。
通配符 1.0.* 你可以使用通配符来指定一种模式。1.0.与>=1.0,<1.1是等效的。
赋值运算符 ~1.2 这对于遵循语义化版本号的项目非常有用。~1.2相当于>=1.2,<2.0。

下一个重要版本（波浪号~运算符）

~ 最好用例子来解释： ~1.2 相当于 >=1.2,<2.0，而 ~1.2.3 相当于 >=1.2.3,<1.3。正如你所看到的这对于遵循语义化版本号的项目最有用。一个常见的用法是标记你所依赖的最低版本，像 ~1.2（允许1.2以上的任何版本，但不包括2.0）。由于理论上直到2.0应该都没有向后兼容性问题，所以效果很好。你还会看到它的另一种用法，使用~指定最低版本，但允许版本号的最后一位数字上升。

注意： 虽然 2.0-beta.1 严格地说是早于 2.0，但是，根据版本约束条件， 例如~1.2却不会安装这个版本。就像前面所讲的~1.2只意味着.2部分可以改变，但是1.部分是固定的。

稳定性

默认情况下只有稳定的发行版才会被考虑在内。如果你也想获得 RC、beta、alpha 或 dev 版本，你可以使用 稳定标志。你可以对所有的包做最小稳定性(minimum-stability)设置，而不是每个依赖逐一设置。

minimum-stability (root-only)

这定义了通过稳定性过滤包的默认行为。默认为 stable（稳定）。因此如果你依赖于一个 dev（开发）包，你应该明确的进行定义。

对每个包的所有版本都会进行稳定性检查，而低于 minimum-stability 所设定的最低稳定性的版本，将在解决依赖关系时被忽略。对于个别包的特殊稳定性要求，可以在 require 或 require-dev 中设定(见上文说明)。

可用的稳定性标识（按字母排序）：dev、alpha、beta、RC、stable。