composer学习

Composer是PHP的依赖管理工具,它允许你声明项目所依赖的代码库并自动安装。本文介绍了Composer的安装、基本用法、包的管理、自动加载、命令行工具以及Composer.json的架构,包括如何发布和更新包,以及如何处理依赖关系和版本约束。通过Composer,你可以轻松管理和维护项目中的第三方库和依赖关系。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

简介

  • Composer是PHP的一个依赖管理工具,他允许你申明项目所依赖的代码库,他会你的项目中为你安装他们。
  • 依赖管理
  • Composer不是一个包管理器,它涉及packages和libraries,它在每个项目的基础上进行管理
  • Composer 将这样为你解决问题:
  1. 一个项目依赖于若干个库
  2. 其中一些库依赖于其他库
  3. 你申明你所依赖的东西
  4. Composer会找出那个版本的包需要安装,并安装它们(将它们下载到你的项目中)
  • 系统要求
  • Composer需要5.3.2+以上版本

安装

*nix

  • 下载
    局部安装:这种方式是直接下载一个PHP的归档文件直接使用;
php -r "readfile('https://getcomposer.org/installer');" | php

或者指定安装

curl -sS https://getcomposer.org/installer | php -- --install-dir=bin

全局安装:将此文件放进系统PATH目录,你就能全局访问他,甚至在使用的时候都可以不用使用php前缀


curl -sS https://getcomposer.org/installer | php

mv composer.phar /usr/local/bin/composer

windows安装

安装程序下载Composer-SetUp.exe;下载安装后默认帮你设置好环境变量,因此你就可以在全局使用composer命令;
手动安装:下载composer.phar文件并设置好环境变量PATH

cd C:\Users\Administrator\bin
php -r "readfile('https://getcomposer.org/installer');" | php

在composer.phar同级目录下新建composer.bat文件;.bat的文件名称将是你使用composer的别名

echo @php "%~dp0composer.phar" %*>composer.bat

关闭窗口进行测试

composer -V

基本用法

composer.json:项目安装

要在项目中使用composer,你需要一个composer.json文件。此文件包含了一些项目的依赖和一些其他的元数据

关于require Key
  • composer.json做的第一件事就是申明你项目的依赖
{
    "require" : {
       "monolog/monolog" : "1.0.*",
    }
}

require关键词申明依赖,例如包monolog/monolog对应的包版本1.0.*
包名称:包名称有供应商名称和项目名称构成。通常容易产生相同的项目名称,而供应商名称的存在解决了名称冲突的问题。他允许两个不同的人创建同样名为json的库,而他们将被名为为 igorw/json和seldaek/json

包版本:前面的monolog指定的版本为1.0.*。这表示 任何从1.0开始的开发分支它都会匹配,它会匹配1.0.0、1.0.20。
版本约束可以用不同的方法来指定

名称实例描述
确切的版本号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应该都没有向后兼容性问题,所以效果很好。你还会看到它的另一种用法,使用 ~ 指定最低版本,但允许版本号的最后一位数字上升

稳定性

默认下只有稳定发行的版本才被考虑在内,如果你想活得RC、beta、alpha或dev版本

关键词解释
alpha内部测试版,α是希腊字母的第一个,表示最早的版本,一般用户不要下载这个版本,这个版本包含很多BUG,功能也不全,主要是给开发人员和 测试人员测试和找BUG用的。
beta公开测试版。β是希腊字母的第二个,顾名思义,这个版本比alpha版发布得晚一些,主要是给“部落”用户和忠实用户测试用的,该版本任然存 在很多BUG,但是相对alpha版要稳定一些。这个阶段版本的软件还会不断增加新功能。如果你是发烧友,可以下载这个版本
RC全写:Release Candidate(候选版本),该版本又较beta版更进一步了,该版本功能不再增加,和最终发布版功能一样。这个版本有点像最终发行版之前的一个类似 预览版,这个的发布就标明离最终发行版不远了。作为普通用户,如果你很急着用这个软件的话,也可以下载这个版本
stable稳定版。在开源软件中,都有stable版,这个就是开源软件的最终发行版,用户可以放心大胆的用了
RTM商业软件;称为Release to Manufacture。工厂版。改版程序已经固定,就差工厂包装、光盘印图案等工作了
OEM商业软件;称为Release to Manufacture。工厂版。改版程序已经固定,就差工厂包装、光盘印图案等工作了
EVAL商业软件;评估版。就是有30或者60天等使用期限的版本
RTL商业软件;Retail.(零售版),这个版本就是真正发售的版本,有漂亮的包装、光盘、说明书等东西和高昂的价格
Composer.lock-锁文件

安装依赖后,composer会将安装的确切版本写入到composer.lock文件,这个文件将锁定更改项目的特定版本
composer.lock的作用: 任何建立项目的人都会下载与指定版本相同的依赖。持续集成服务器、生产环境、你团队中的开发人员、每件事、每个人都使用相同的依赖,从而减少潜在的错误对部署的影响。即使你独自开发的项目,在六个月内重新安装项目时,你也可以放心的继续工作,即使从那时起你的依赖以及发布了很多新的版本。

注意:提交项目时应将你的comoser.json和composer.lock文件都提交到你的项目库里,因为composer install命令将会检查composer.lock文件是否存在,如果存在将下载指定版本;不会使用composer.json文件,composer.lock文件存在将会被忽略,如果不存在将会读取Composer.json文件创建新的Composer.lock文件,如果你要更新你的依赖,请使用update 命令。这将会获取最新匹配的版本(根据你Composer.json文件),并将版本更新进Composer.lock文件

php composer.phar  update

如果你只想更新部分依赖,你可以通过设置白名单的方式实现

php composer.phar nupdate monolog/monolog
自动加载

对于库的自动加载信息,Composer生成了一个vendor/autoload.php文件,引入这个文件将会获得自动加载的支持

require 'vendor/autoload.php';

引入了自动加载文件,很容易的就可以使用第三方库,例如:你的项目依赖monolog

$log = new Monolog\Logger('name');$log->pushHandler(new Monolog\Handler\StreamHandler('app.log', Monolog\Logger::WARNING));

$log->addWarning('Foo');

你可以在Composer.json文件autoload字段增加自己的autoloader,例如:

{
    "autoload": {
            "psr-4": {"Acme\\","src/"}
   }
}

Composer将注册一个PSR-4的autoload到Acme的空间
你可以定义一个命名空间到目录的映射,此时src会在你的项目根目录,与vendor文件夹同级。例如 src/Foo.php文件就会加载Acme\Foo类
注意:映射格式为你定义的命名空间名称,必须对应到你申明的命令空间根目录地址;例如上面的定义的Acme命令空间映射的位置是

  • 案例:monolog项目
    Composer.json配置的自动加载
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2L8uLSe8-1596550893770)(en-resource://database/516:1)]
    文件格式
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-biu55WkH-1596550893773)(en-resource://database/518:1)]
    命名空间:命名空间都是一项目名称开始申明

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ikrINWW5-1596550893776)(en-resource://database/524:1)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1OwktvO1-1596550893779)(en-resource://database/522:1)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-P8vO5sSD-1596550893780)(en-resource://database/526:1)]
引入autoload.php这个文件将autoloader的实例,你可以将的返回之存储在变量中来加载更多的命名空间,例如:

$loader = require 'vendor/autoload.php';
$loader->add('Acme\\Test\\', __DIR__);

Composer提供了自己的autoloader,如果你不想使用它,你可以只引入 vendor/composer/autoload_*.php文件,它返回一个关联数组,可以通过自己的关联数组配置自己的autoloader 示例:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VN5Xqi33-1596550893782)(en-resource://database/528:1)]

库(资源包)

每个项目都是一个包

只要你有composer.json文件在你的项目中,那么整个目录就是一个包。当你添加一个require到你的项目中,你就是在创建一个依赖于其他库的包。你的项目和库之间的区别是,你的项目是一个没有名字的包
为了使它成为可安装的包,你需要给你的项目取一个名称。通过composer.jsonname来定义

{
    "name": "acme/hello_world",
    "require": {
        "monolog/monolog": "1.0.*"
    }
}

这种情况下项目的名称为acme/hello_world,其中acme是供应商的名称,供应商的名称必须填写

注意: 如果你不知道那什么作为供应商的名称,那么使用你github上的用户名是个不错的选择。虽然包名不区分大小写,但是惯例是使用小写字母,并使用连接字符作为单词分割

平台软件包

Composer 将那些已经安装在系统上,但不是由Composer安装的包视为一个虚拟的平台软件包,这包含PHP本身,PHP扩展和一些系统库。

  • PHP表示用户的PHP版本要求,你可以对其作出限制,例如限制>=5.4.0。如果需要64位版本的PHP,你可以使用php-64bit
  • hhvm代表的是HHVM(也就是HipHop vitual Machine)运行环境的版本,允许你设置一个版本的限制,例如:’>=2.3.3’
  • ext-<name>可以帮你指定需要的PHP扩展(包括核心扩展)。通常PHP拓展的版本可以是不一致的,将他们的约束版本约束为*是一个不错的注意。一个PHP扩展包的例子:包名字可以写成ext-gd
  • lib-<name>允许对PHP库的版本库进行限制。以下是可供使用的名称curl、iconv、icu、libxml、openssl、pcre、uuid、xsl
    你可以是用composer show --platform 来查看可用的软件包列表。
指明版本
  • 你需要一些方法来指明自己开的包的版本,当你在packagist上发布自己的包,它能够从VCS(git、svn、hg)的信息推断出包的版本,因此你不必指明包的版本号, 并且也不建议这样做。 请看下面标签和分支来了解版本号是如何被提取的
    如果你要手动创建并且明确的指定它,你只需要添加一个version字段:
   {
        "version": "1.0.0"
   }

注意: 你应该尽量避免手动设置版本,因为标签的只必须与标签的名像匹配

标签

对于每一个看起来像版本号的标签,都会相应的创建一个包的版本。他应该符合‘X.Y.Z’或者’vX.Y.Z’的形式, -patch,-alpha、beta、-RC这些后缀都是可选的,在后缀之后也可以在跟上一个数字
下面是有效标签名称的几个例子

  • 1.0.0
  • v1.0.0
  • 1.10.5-RC1
  • v4.4.4beta2
  • v2.0.0-aplha
  • v2.0.4-p1

注意: 即使你的标签带有前缀v,由于在require一个版本的约束时是不允许这种前缀的,因此v将被省略(例如:标签v1.0.0将创建1.0.0的版本)

分支

对于每一个分支,都会相应的创建一个包的开发版本。如果分支看起来很像一个版本号,那么将创建一个如同{分支名}-dev的版本号。例如一个分支2.0将产生一个2.0.x-dev的包版本(加入了.*是出于技术的原因,以确保它被识别为一个分支,而2.0.x的分支名称也是允许的,同样也会被转化为2.0.x-dev)。如果分支开起来不像一个版本,它将会创建dev-{分支名} 形式的版本号。例如master将产生一个dev-master的版本号
下面是一些分支版本的示例:

  • 1.x
  • 1.0(equals 1.0.x )
  • 1.1.x

注意: 当你安装一个新的版本时,它将自动从source中拉取

别名

它表示一个包版本的别名。例如你可以为dev-master设置一个别名1.0.x-dev,这样就可以通过require 1.0.x-dev来得到dev-master版本的包

为什么使用别名

当你使用 VCS 资源库,你将只会得到类似于这样的版本号:从分支发布的标签获取,它看起来像 2.0 或 2.0.x。比较特殊的是,对于你的 master 分支,你会得到一个最新提交的 dev-master 版本。对于你的 bugfix 分支,你会得到一个最新提交的 dev-bugfix 版本。以此类推,这些特殊的版本标识可以用来获取最新的分支源码。

如果你的 master 分支使用标签发布了 1.0 系列版本,即 1.0.1、1.0.2、1.0.3 等等,任何依赖它的资源包都可能会使用 1.0.* 这个版本约束。

如果有人想要最新的 dev-master 版本,他们将会碰到一个问题:另一些依赖它的包可能使用了 1.0.* 这个版本约束,因此在 require 这个开发版本时将会产生冲突,因为 dev-master 不符合 1.0.* 的约束。这时,就可以使用别名。

  • 分支别名

dev-master 指向一个在你 VCS 项目上的主分支。有些用户会想要使用最新的开发版本,这是相当常见的情况。因此,Composer 允许你别名你的 dev-master 版本为一个 1.0.x-dev 的版本号。这是通过在 composer.json 文件中的 extra 下指定 branch-alias 字段来完成的:

{
    "extra": {
        "branch-alias": {
            "dev-master": "1.0.x-dev"
        }
    }
}

此处的分支别名必须是以dev-开头(不可比较的版本名称),对应的别名是可比较的开发版本名称(即以数字开头,并以.x-dev结束)。branch-alias所引起的分支必须存在,对于dev-master你需要在master分支上提交它。

其结果是,任何人都可以使用1.0.*版本约束来得到dev-master版本。
为了定义分支别名,你必须是需要别名的包的所有者。如果你想别名一个第三方包,而又不想fork它到自己的版本库,可以使用行内别名

行内别名

分支别名是非常适合主开发的分支,但是使用他们的前提,你需要有对源码的控制权限,并且你要提交别名的修改到你控制的版本库
使用情景:

  • 当你只想在本地项目修复一些依赖包的bug修正时,你可以直接在requirerequire-dev字段中直接使用你需要的包,例如:你找到了monolog/monolog的一个bug时,symfony/monolog-bundle require了monolog/monolog,并约束了版本限定为1.*;因此你可以这样做,将github上的克隆一份,并在bugfix的分支上修复它,然后使用这个包的操作如下

{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/you/monolog"
        }
    ],
    "require": {
        "symfony/monolog-bundle": "2.0",
        "monolog/monolog": "dev-bugfix as 1.0.x-dev"
    }
}

它将在你的GitHub上获取monolog/monolog 的dev-bugfix版本并将其命名为1.0.x-dev

注意:
如果要对一个资源包使用行内别名,这个别名(as 的右边)必须能够使用版本约束。as左边的部分在这之后将被丢弃。因此,如果 A 依赖 B 而 B 又依赖 monolog/monolog 且版本约束为 dev-bugfix as 1.0.x-dev,那么安装 A 时将使用 B 的版本约束,并识别为 1.0.x-dev,此时必须真实存在一个“分支别名”或“1.0 系列分支”。否则就必须在 A 的 composer.json 文件中再次定义行内别名。

注意: 应该尽量避免行内别名,特别是对已经发布的包。如果你发现了一个 bug,请尝试将你的修复合并到上游分支。这将避免使用你资源包的用户出现问题。

锁文件

始终针对同一个版本进行测试。任何时候,这个锁文件都只会对你的项目产生影响

发布vcs(线上版本控制系统)

一旦你有一个包含composer.json文件的存储库在线上的版本控制系统(列如:git) ,你的库就可以被composer所安装。在这个例子中,我们将 acme/hello-world 库发布在 GitHub 上的 github.com/username/hello-world 中。

现在测试这个 acme/hello-world 包,我们在本地创建一个新的项目。我们将它命名为 acme/blog。此博客将依赖 acme/hello-world,而后者又依赖 monolog/monolog。我们可以在某处创建一个新的 blog 文件夹来完成它,并且需要包含 composer.json 文件:

{
    "name": "acme/blog",
    "require": {
        "acme/hello-world": "dev-master"
    }
}

在这个例子中 name 不是必须的,因为我们并不想将它发布为一个库。在这里为 composer.json 文件添加描述。

现在我们需要告诉我们的应用,在哪里可以找到 hello-world 的依赖。为此我们需要在 composer.json 中添加 repositories 来源申明:

{
    "name": "acme/blog",
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/username/hello-world"
        }
    ],
    "require": {
        "acme/hello-world": "dev-master"
    }
}

这就是全部了。你现在可以使用 Composer 的 install 命令来安装你的依赖包了!

小结: 任何含有 composer.json 的 GIT、SVN、HG 存储库,都可以通过 require 字段指定“包来源”和“声明依赖”来添加到你的项目中。

发布到 packagist

好的,你现在可以发布你的包了,但你不会希望你的用户每次都这样繁琐的指定包的来源。

你可能注意到了另一件事,我们并没有指定 monolog/monolog 的来源。它是怎么工作的?答案是 packagist。

Packagist 是 Composer 主要的一个包信息存储库,它默认是启用的。任何在 packagist 上发布的包都可以直接被 Composer 使用。就像 monolog 它被 发布在 packagist 上,我们可以直接使用它,而不必指定任何额外的来源信息。

如果我们想与世界分享我们的 hello-world,我们最好将它发布到 packagist 上。这样做是很容易的。

你只需要点击那个大大的 “Submit Package” 按钮并注册。接着提交你库的来源地址,此时 packagist 就开始了抓取。一旦完成,你的包将可以提供给任何人使用。

命令行

全局参数

下列每一个参数可以和每一个命令结合使用

  • – verbose(-v) :增加反馈信息的详细度
    • -v 正常输出
    • -vv 详细输出
    • -vvv debug
  • –help :帮助信息
  • –quiet(-q) :禁止输出任何信息
  • –no-interaction (-n): 不要询问任何交互问题
  • –working-dir(-d) :如果指定的话,将使用指定的目录作为工作目录
  • –profile :显示时间和内存的使用信息
  • –ansi:强制ANSI输出
  • –no-ansi:关闭ANSI输出
  • –version (-v):显示当前程序的版本信息
进程退出代码
  • 0 :正常
  • 1:通用/未知错误
  • 2:依赖关系处理错误
初始化 init

创建Composer.json文件除了手动创建以为,还可以使用命令 init 来创建

composer init
初始化参数
  • –name:包的名称
  • –description:包的描述
  • –author:包的作者
  • –homepage:包的主页
  • –require:需要依赖的其它包,必须有一个版本约束。并且应该遵循foo/bar:1.0.0这样的格式
  • –require-dev 开发版的依赖包,内容格式与require格式相同
  • –stability(-s):minimun-stability字段的值
安装

install命令从当前目录读取composer.json文件,处理依赖关系,并安装到vendor目录,如果当前目录存在composer.lock文件,将会读取此文件的依赖关系,而不会去读取composer.json文件。如果不存在composer.lock文件,composer在读取完成composer.json文件将会生成它

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

为了获取依赖的最新版本,并且升级composer.lock文件

php composer.phar update

这将解决项目的所有依赖,并将确切的版本号写入 composer.lock。

如果你只是想更新几个包,你可以像这样分别列出它们:

php composer.phar update vendor/package vendor/package2

你还可以使用通配符进行批量更新:

php composer.phar update vendor/*
更新-参数
  • –prefer-source:当有可用的包时,从 source 安装。
  • –prefer-dist:当有可用的包时,从 dist 安装
  • –dry-run:模拟命令,并没有做实际的操作
  • –dev:安装require-dev字段列出的包(这是一个默认值)
  • –on-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 同时更新白名单内包的依赖关系,这将进行递归更新
申明依赖require

require 命令增加新的依赖包到当前目录的 composer.json 文件中

php composer.phar require

在添加或改变依赖时, 修改后的依赖关系将被安装或者更新。

如果你不希望通过交互来指定依赖包,你可以在这条令中直接指明依赖包。

php composer.phar require vendor/package:2.* vendor/package2:dev-master
申明依赖-参数
  • –prefer-source:当有可用的包时,从 source 安装。
  • –prefer-dist:当有可用的包时,从 dist 安装
  • –dev:安装require-dev字段列出的包(这是一个默认值)
  • –on-update:禁止依赖关系的自动更新
  • –on-dev:跳过require-dev字段列出的包
  • –no-progress:移除进度信息,这可以避免一些不处理换行的终端或脚本出现混乱的显示。
  • –update-with-dependencies 一并更新新装包的依赖
全局执行 global

global 命令允许你在 COMPOSER_HOME 目录下执行其它命令,像 install、require 或 update。

并且如果你将  C O M P O S E R H O M E / v e n d o r / b i n   加 入 到 了   COMPOSER_HOME/vendor/bin 加入到了  COMPOSERHOME/vendor/bin  PATH 环境变量中,你就可以用它在命令行中安装全局应用,下面是一个例子:

php composer.phar global require fabpot/php-cs-fixer:dev-master

现在 php-cs-fixer 就可以在全局范围使用了(假设你已经设置了你的 PATH)。如果稍后你想更新它,你只需要运行 global update:

php composer.phar global update
搜索 search

search 命令允许你为当前项目搜索依赖包,通常它只搜索 packagist.org 上的包,你可以简单的输入你的搜索条件。

php composer.phar search monolog
搜索-参数
  • –only-name (-N): 仅针对指定的名称搜索(完全匹配)
展示 show

如果你想看到一个包的详细信息,你可以输入一个包名称。

php composer.phar show monolog/monolog

你甚至可以输入一个软件包的版本号,来显示该版本的详细信息。

php composer.phar show monolog/monolog 1.0.2
展示-参数
  • –installed (-i): 列出已安装的依赖包。
  • –platform (-p): 仅列出平台软件包(PHP 与它的扩展)。
  • –self (-s): 仅列出当前项目信息。
依赖性检测 depends

depends 命令可以查出已安装在你项目中的某个包,是否正在被其它的包所依赖,并列出他们。

php composer.phar depends --link-type=require monolog/monolog
有效性检测 validate

在提交 composer.json 文件,和创建 tag 前,你应该始终运行 validate 命令。它将检测你的 composer.json文件是否是有效的

php composer.phar validate
有效性检测参数
  • –no-check-all: Composer 是否进行完整的校验。
依赖包状态检测 status

如果你经常修改依赖包里的代码,并且它们是从 source(自定义源)进行安装的,那么 status 命令允许你进行检查,如果你有任何本地的更改它将会给予提示。

php composer.phar status

你可以使用 --verbose 系列参数(-v|vv|vvv)来获取更详细的详细:


php composer.phar status -v
自我更新 self-update

将 Composer 自身升级到最新版本,只需要运行 self-update 命令。它将替换你的 composer.phar 文件到最新版本。

如果你已经为整个系统安装 Composer(参见 全局安装),你可能需要在 root 权限下运行它:

sudo composer self-update
自我更新-参数
  • –rollback (-r): 回滚到你已经安装的最后一个版本。
  • –clean-backups: 在更新过程中删除旧的备份,这使得更新过后的当前版本是唯一可用的备份
更改配置 config

config 命令允许你编辑 Composer 的一些基本设置,无论是本地的 composer.json 或者全局的 config.json文件。

php composer.phar config --list
更改配置-使用方法

config [options] [setting-key] [setting-value1] ... [setting-valueN]

setting-key 是一个配置选项的名称,setting-value1 是一个配置的值。可以使用数组作为配置的值(像 github-protocols),多个 setting-value 是允许的

更改配置-参数
  • –global (-g): 操作位于 $COMPOSER_HOME/config.json 的全局配置文件。如果不指定该参数,此命令将影响当前项目的 composer.json 文件,或 --file 参数所指向的文件。
  • –editor (-e): 使用文本编辑器打开 composer.json 文件。默认情况下始终是打开当前项目的文件。当存在 --global 参数时,将会打开全局 composer.json 文件。
  • –unset: 移除由 setting-key 指定名称的配置选项。
  • –list (-l): 显示当前配置选项的列表。当存在 --global 参数时,将会显示全局配置选项的列表
  • –file="…" (-f): 在一个指定的文件上操作,而不是 composer.json。注意:不能与 --global 参数一起使用。
修改包来源

除了修改配置选项,config还支持通过以下方式来修改包的来源信息:

php composer.phar config repositories.foo vcs http://github.com/foo/bar
创建项目 create-project

你可以使用composer从现有的包中创建一个新的项目。这相当于执行了一个git clone或者svn checkout命令后将这个包的依赖安装到他们自己的vendor目录

此命令的常见用途:

  1. 你可以快速的部署你的应用。
  2. 你可以检出任何资源包,并开发它的补丁。
  3. 多人开发项目,可以用它来加快应用的初始化。

要创建基于 Composer 的新项目,你可以使用 “create-project” 命令。传递一个包名,它会为你创建项目的目录。你也可以在第三个参数中指定版本号,否则将获取最新的版本。如果该目录目前不存在,则会在安装过程中自动创建。

php composer.phar create-project doctrine/orm path 2.2.*

此外,你也可以无需使用这个命令,而是通过现有的 composer.json 文件来启动这个项目。
默认情况下,这个命令会在 packagist.org 上查找你指定的包。

创建项目-参数
  • –repository-url: 提供一个自定义的储存库来搜索包,这将被用来代替 packagist.org。可以是一个指向composer 资源库的 HTTP URL,或者是指向某个 packages.json 文件的本地路径。
  • –stability (-s): 资源包的最低稳定版本,默认为 stable
  • –prefer-source: 当有可用的包时,从 source 安装。
  • –prefer-dist: 当有可用的包时,从 dist 安装。
  • –dev: 安装 require-dev 字段中列出的包。
  • –no-install: 禁止安装包的依赖
  • –no-plugins: 禁用 plugins。
  • –no-scripts: 禁止在根资源包中定义的脚本执行。
  • –no-progress: 移除进度信息,这可以避免一些不处理换行的终端或脚本出现混乱的显示
  • –keep-vcs: 创建时跳过缺失的 VCS 。如果你在非交互模式下运行创建命令,这将是非常有用的。
打印自动加载索引dump-autoload

某些情况下你需要更新autoloader,例如你的包加入了一个新的类,你可以使用dump-autoload来完成,而不不需要使用install或者upload命令

此外,它可以打印一个优化过的,符合 PSR-0/4 规范的类的索引,这也是出于对性能的可考虑。在大型的应用中会有许多类文件,而 autoloader 会占用每个请求的很大一部分时间,使用 classmaps 或许在开发时不太方便,但它在保证性能的前提下,仍然可以获得 PSR-0/4 规范带来的便利。

打印自动加载索引-参数
  • –optimize (-o): 转换 PSR-0/4 autoloading 到 classmap 获得更快的载入速度。这特别适用于生产环境,但可能需要一些时间来运行,因此它目前不是默认设置。
  • –no-dev: 禁用 autoload-dev 规则。
查看许可协议  licenses

列出已安装的名称、版本、许可协议。使用–format=json 来获得json格式的输出

执行脚本run-script

你可以运行此命令来手动执行 脚本,只需要指定脚本的名称,可选的 --no-dev 参数允许你禁用开发者模式。

诊断 diagnose

如果你觉得发现了一个 bug 或是程序行为变得怪异,你可能需要运行 diagnose 命令,来帮助你检测一些常见的问题。

php composer.phar diagnose
归档 archive

此命令用来对指定包的指定版本进行 zip/tar 归档。它也可以用来归档你的整个项目,不包括 excluded/ignored(排除/忽略)的文件

php composer.phar archive vendor/package 2.0.21 --format=zip
归档-参数
  • –format (-f): 指定归档格式:tar 或 zip(默认为 tar)
  • –dir: 指定归档存放的目录(默认为当前目录)。
获取帮助信息 help

使用 help 可以获取指定命令的帮助信息。

php composer.phar help install
环境变量

你可通过一些环境变量来覆盖默认的配置,建议你尽量在composer.json文件中的config字段来设置这些值,而不是通过命令来设置环境变量需要注意的是:环境变量中设置的值,将优先于composer.json中所指定的值

变量描述
COMPOSER为composer.json文件指定其他的文件名
COMPOSER_ROOT_VERSION通过设置这个环境变量,你可以指定 root 包的版本,如果程序不能从 VCS 上猜测出版本号,并且未在 composer.json 文件中申明
COMPOSER_VENDOR_DIR通过设置这个环境变量,你可以指定 composer 将依赖安装在 vendor 以外的其它目录中
COMPOSER_BIN_DIR通过设置这个环境变量,你可以指定 bin(Vendor Binaries)目录到 vendor/bin 以外的其它目录。
http_proxy or HTTP_PROXY设置HTTP 代理,建议使用 http_proxy(小写)或者两者都进行定义。因为某些工具,像 git 或 curl 将使用 http_proxy 小写的版本。另外,你还可以使用 git config --global http.proxy  来单独设置 git 的代理。
no_proxy如果你是使用代理服务器,并且想要对某些域名禁用代理,就可以使用 no_proxy 环境变量。只需要输入一个逗号相隔的域名 排除 列表。此环境变量接受域名、IP 以及 CIDR地址块。你可以将它限制到一个端口(例如::80)。你还可以把它设置为 * 来忽略所有的 HTTP 代理请求。
HTTP_PROXY_REQUEST_FULLURI如果你使用了 HTTP 代理,但它不支持 request_fulluri 标签,那么你应该设置这个环境变量为 false 或 0,来防止 composer 从 request_fulluri 读取配置。
HTTPS_PROXY_REQUEST_FULLURI如果你使用了 HTTPS 代理,但它不支持 request_fulluri 标签,那么你应该设置这个环境变量为 false 或 0 ,来防止 composer 从 request_fulluri 读取配置。
COMPOSER_HOMECOMPOSER_HOME 环境变量允许你改变 Composer 的主目录。这是一个隐藏的、所有项目共享的全局目录(对本机的所有用户都可用)。
COMPOSER_HOME/config.json你可以在 COMPOSER_HOME 目录中放置一个 config.json 文件。在你执行 install 和 update 命令时,Composer 会将它与你项目中的 composer.json 文件进行合并。若 全局 和 项目 存在相同配置项,那么项目中的 composer.json 文件拥有更高的优先级。
COMPOSER_CACHE_DIRCOMPOSER_CACHE_DIR 环境变量允许你设置 Composer 的缓存目录,这也可以通过 cache-dir 进行配置。
COMPOSER_PROCESS_TIMEOUT这个环境变量控制着 Composer 执行命令的等待时间(例如:git 命令)。默认值为300秒(5分钟)。
COMPOSER_DISCARD_CHANGES这个环境变量控制着 discard-changes config option。
COMPOSER_NO_INTERACTION如果设置为1,这个环境变量将使 Composer 在执行每一个命令时都放弃交互,相当于对所有命令都使用了 --no-interaction。可以在搭建 虚拟机/持续集成服务器 时这样设置。

composer.json 架构

json schema

参考:json schemares/composer-schema.json

root包

"root 包”是指由 composer.json 定义的在你项目根目录的包。这是 composer.json 定义你项目所需的主要条件。(简单的说,你自己的项目就是一个 root 包)

某些字段仅适用于“root 包”上下文。 config 字段就是其中一个例子。只有“root 包”可以定义。在依赖包中定义的 config 字段将被忽略,这使得 config 字段只有“root 包”可用(root-only)。如果你克隆了其中的一个依赖包,直接在其上开始工作,那么它就变成了“root 包”。与作为他人的依赖包时使用相同的 composer.json 文件,但上下文发生了变化。

注意: 一个资源包是不是“root 包”,取决于它的上下文。 例:如果你的项目依赖 monolog 库,那么你的项目就是“root 包”。 但是,如果你从 GitHub 上克隆了 monolog 为它修复 bug, 那么此时 monolog 就是“root 包”。

属性
包名 name

他包含供应商的名称和项目的名称,使用/分割,对于需要发布的包(库),这个是必须填写的

描述 description

一个包的简短描述,对于需要发布的包(库),这个是必须填写的

版本 version

version 不是必须的,并且建议忽略。通常,我们能够从 VCS (git, svn, hg) 的信息推断出包的版本号,在这种情况下,我们建议忽略

注意: Packagist 使用 VCS 仓库, 因此 version 定义的版本号必须是真实准确的。 自己手动指定的 version,最终有可能在某个时候因为人为错误造成问题。

安装类型

安装包的类型,默认为library。包的安装类型,用来定义安装逻辑。如果你的包需要一个特殊的逻辑,你可以设定一个自定义的类型。这些类型都是将到具体的某一个项目 ,而对应的项目将是提供一种能够安装改类型包的安装程序。
composer原生支持一下几种类型:

  • library: 他是默认类型,它会简单的将文件复制到vendor目录
  • project:这表示当前包是一个项目,而不是一个库
  • metapackage:当一个空的包,包含依赖并且触发依赖的安装,他将不会对系统写入文件,因此这种安装类型不需要sourcedist
  • composer-plugin:一个安装类型为composer-plugin的包,他有自定义安装类型,可以为其包提供一个install

仅在你需要一个自定义的安装逻辑时才使用它。建议忽略这个属性,采用默认的 library。

关键词keywords

包含相关关键词的数组。可用于搜索和过滤

项目主页homepage

改项目网站的url地址 可选

版本发布时间time

版本的发布时间,必须符合YYYY-MM-DDYYYY-MM-DD HH:MM:SS的格式
可选

许可协议 license

包的许可协议,他可以是一个字符串或者字符串数组
常见的许可协议:

  • Apache-2.0
  • BSD-2-Clause
  • BSD-3-Clause
  • BSD-4-Clause
  • GPL-2.0
  • GPL-2.0+
  • GPL-3.0
  • GPL-3.0+L
  • GPL-2.1L
  • GPL-2.1+L
  • GPL-3.0L
  • GPL-3.0+
  • MIT

对于闭源软件,你必须使用 “proprietary” 协议标识符。

一个例:

{
    "license": "MIT"
 }

对于一个包,当允许在多个许可协议间进行选择时(“disjunctive license”),这些协议标识符可以被指定为数组。

多协议的一个例:

{
    "license": [
       "LGPL-2.1",
       "GPL-3.0+"
    ]
}

另外它们也可以由 “or” 分隔,并写在括号中:

{
    "license": "(LGPL-2.1 or GPL-3.0+)"
}

同样,当有多个许可协议需要结合使用时(“conjunctive license”),它们应该被 “and” 分隔,并写在括号中。

作者 author

一个包的作者,这是一个数组对象
这个对象必须包含以下属性

  • name :作者的名称
  • email:作者的邮箱
  • homepage:作者主页的url地址
  • role:作者的角色
    一个示例:
{
    "authors": [
        {
            "name": "Nils Adermann",
            "email": "naderman@naderman.de",
            "homepage": "http://www.naderman.de",
            "role": "Developer"
        },
        {
            "name": "Jordi Boggiano",
            "email": "j.boggiano@seld.be",
            "homepage": "http://seld.be",
            "role": "Developer"
        }
    ]
}
支持 support

活动项目支持的相关信息对象。这个数组必须包含以下属性

  • email :项目支持的url地址
  • issues:跟踪文档的url地址
  • forum:论坛地址
  • wiki:wiki地址
  • irc:IRC视频聊天地址,似于 irc://server/channel。
  • source:网址浏览或者下载源。
    一个实例:

{
    "support": {
        "email": "support@example.org",
        "irc": "irc://irc.freenode.org/composer"
    }
}
package links

下面提到所有对象,都应该是包名到版本的映射对象
实例


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

所有的这些都是可选的
requirerequire-dev还支持稳定性标签,(@,针对的’root’包)。这允许你在minimun-stability设置的范围外做进一步的限制或扩展。例如:你想依赖一个不稳定的包可以在一个版本的约束后使用它,或者是一个空的版本约束内使用

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

如果你的依赖之一,有对另一个不稳定包的依赖,你最好在require中显示的定义它,并带上足够详细的稳定标识,
实例

{
    "require": {
        "doctrine/doctrine-fixtures-bundle": "dev-master",
        "doctrine/data-fixtures": "@dev"
    }
}

require 和 require-dev 还支持对 dev(开发)版本的明确引用(即:版本控制系统中的提交编号 commit),以确保它们被锁定到一个给定的状态,即使你运行了更新命令。你只需要明确一个开发版本号,并带上诸如 # 的标识。

实例:

{
    "require": {
        "monolog/monolog": "dev-master#2eb0c0978d290a1c45346a1955188929cb4e5db7",
        "acme/foo": "1.0.x-dev#abc123"
    }
}

注意: 虽然这有时很方便,但不应该长期在你的包中使用,因为它有一个技术上的限制。 composer.json 将仍然在哈希值之前指定的分支名称读取元数据, 正因为如此,在某些情况下,它不会是一个实用的解决方法, 如果可能,你应该总是尝试切换到拥有标签的版本。

它也可以应用于行内别名,这样它将匹配一个约束,否则不会。更多信息请参考 别名。

require

必须的软件包列表,除非这些依赖被满足,否则不会完成安装。

require-dev (root-only)

这个列表是为开发或测试等目的,额外列出的依赖。“root 包”的 require-dev 默认是会被安装的。然而 install或 update 支持使用 --no-dev 参数来跳过 require-dev 字段中列出的包。

conflict

此列表中的包与当前包的这个版本冲突。它们将不允许同时被安装。

请注意,在 conflict 中指定类似于 <1.0, >= 1.1 的版本范围时,这表示它与小于1.0 并且 同时大等于1.1的版本冲突,这很可能不是你想要的。在这种情况下你可能想要表达的是 <1.0 | >= 1.1 。

replace

这个列表中的包将被当前包取代。这使你可以 fork 一个包,以不同的名称和版本号发布,同时要求依赖于原包的其它包,在这之后依赖于你 fork 的这个包,因为它取代了原来的包。

这对于创建一个内部包含子包的主包也非常的有用。例如 symfony/symfony 这个主包,包含了所有 Symfony 的组件,而这些组件又可以作为单独的包进行发布。如果你 require 了主包,那么它就会自动完成其下各个组件的任务,因为主包取代了子包。

注意,在使用上述方法取代子包时,通常你应该只对子包使用 self.version 这一个版本约束,以确保主包仅替换掉子包的准确版本,而不是任何其他版本。

provide

此包提供的其他包的列表。这对于公共接口非常有用。一个包可能依赖于某个虚拟记录器包,任何实现此记录器接口的库都会简单地将其列在provide中

suggest

建议安装的包,它们增强或能够与当前包良好的工作。这些只是信息,并显示在依赖包安装完成之后,给你的用户一个建议,他们可以添加更多的包。
格式如下,版本约束变成了描述信息。

实例:


{
    "suggest": {
        "monolog/monolog": "Allows more advanced logging of the application flow"
    }
}
autoload

PHP autoloader 的自动加载映射。

目前支持PSR-0自动加载、PSR-4自动加载、类映射生成和文件包含。建议使用PSR-4,因为它提供了更大的易用性(添加类时不需要重新生成自动加载程序)

在psr-4模式下,定义了相对于包根目录从名称空间到路径的映射。当自动加载一个类(如Foo\Bar\Baz)时,指向目录src/的名称空间前缀Foo\Baz意味着自动加载程序将查找一个名为src/Bar的文件/Baz.php网站如果有,也包括在内。注意,与旧的PSR-0样式相反,前缀(Foo\)不在文件路径中。

命名空间前缀必须以“\”结尾,以避免类似前缀之间的冲突。例如,Foo将匹配FooBar名称空间中的类,因此后面的反斜杠可以解决问题:Foo\,FooBar\。

在安装/更新期间,PSR-4引用都合并到一个key=>值数组中,该数组可以在生成的文件vendor/composer/autoload_psr4.php中找到。


{
    "autoload": {
        "psr-4": {
            "Monolog\\": "src/",
            "Vendor\\Namespace\\": ""
        }
    }
}

如果需要在多个目录中搜索相同的前缀,可以将其指定为数组,如下所示:


{
    "autoload": {
        "psr-4": { "Monolog\\": ["src/", "lib/"] }
    }
}

如果希望有一个回退目录,其中将查找任何命名空间,则可以使用空前缀,如:


{
    "autoload": {
        "psr-4": { "": "src/" }
    }
}

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值