composer
Posted 虚无缥缈的云
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了composer相关的知识,希望对你有一定的参考价值。
首先介绍php命令行:https://www.cnblogs.com/myjavawork/articles/1869205.html
1.支持命令行必须开启openssl扩展
2.在windows环境下,尽量使用双引号, 在linux环境下则尽量使用单引号来完成。
直接运行文件:
php -f "文件名"
如:php -f "index.php"
直接运行php代码:
php -r "php代码"
如:php -r "var_dump(phpinfo());"
composer的安装:
1最简单方法下载Composer-Setup.exe 安装并配置path变量(他会自动找到php.exe的目录)
2命令行安装:
windows:
1、拷贝远程资源的文件到当前文件夹下文件的名字叫composer-setup.php(即下载composer-setup.php文件) 注意安装前选好目录哦
php -r "copy(\'https://getcomposer.org/installer\', \'composer-setup.php\');"
或者:
php -r "readfile(\'https://getcomposer.org/installer\');" | php
2、检查这个文件的完整性
php -r "if (hash_file(\'sha384\', \'composer-setup.php\') === \'48e3236262b34d30969dca3c37281b3b4bbe3221bda826ac6a9a62d6444cdb0dcd0615698a5cbe587c3f0fe57a54d8f5\') { echo \'Installer verified\'; } else { echo \'Installer corrupt\'; unlink(\'composer-setup.php\'); } echo PHP_EOL;"
3、运行这个文件 这是用命令行安装composer的关键一步
php composer-setup.php
或者指定安装目录:
php composer-setup.php --install-dir=bin
4、删除这个文件
php -r "unlink(\'composer-setup.php\');"
composer 自身的更新:composer self-update
phpstudy 配置全局的composer 或者这篇博文
linux系列: 和windows安装步骤一样的。。。
下载composer-setup.php文件
当前目录:curl -sS https://getcomposer.org/installer | php
指定目录:curl -sS https://getcomposer.org/installer | php -- --install-dir=bin
或者:
php -r "readfile(\'https://getcomposer.org/installer\');" | php
配置号后用composer -v查看成功安装否
php composer 开发自己的包
使用:
命令行进入目标文件夹比如我们要在网站某个项目下安装第三方插件【也可以叫组件】(D:\\xampp\\htdocs\\moodle)
我们需要在moodle的项目文件下下配置创建一个composer.json文件配置如下:
{ "require": { "guzzlehttp/guzzle": "4.2.*",//前面是组件名,后面是组件版本 组件1 "league/csv": "6.0.*", //php组件很多,组件名和版本都可以从https://packagist.org/获得 组件2 "spatie/string": "1.8.*" //组件3 }
安装和更新项目的依赖包与组件
我们在命令行进入当前目录并且配置号上面的composer.json后,在命令行输入composer install 就会下载组件啦 (composer update 是更新组件)
ps:安装时的选择:composer install - 如有 composer.lock 文件,直接安装,否则从 composer.json 安装最新扩展包和依赖;
composer update - 从 composer.json 安装最新扩展包和依赖;
composer update vendor/package - 从 composer.json 或者对应包的配置,并更新到最新; 线上项目慎用!!!他讲会更新所有的组件啊!!如果换到最新的不稳定那就GG了
composer require new/package - 添加安装 new/package, 可以指定版本,如: composer require new/package ~2.5.
composer update foo/bar -只想更新某个特定的库,不想更新它的所有依赖,很简单:
composer require "foo/bar:1.0.0" -
不编辑composer.json
的情况下安装库
使用
回车成功后就可以在moodle文件下下生成一个vendor文件夹并且在vendor文件夹下已经下载好了上面配置的三个组件并且还有一个autoload.php文件专门在项目引用这些组件的
引用这些文件必须先加载autoload.php这个文件,然后实例化每个要使用的组件然后调用他们的方法就行了:
require \'vendor/autoload.php\'; //引入自动加载文件 $client=new \\GuzzleHttp\\Client(); //创建GuzzleHttp组件的对象 $httpResponse=$client->options(); //调用方法
切换国内镜像
默认的组件库时国外的服务器,万恶的网络你懂的我们需要切换到国内的镜像服务器
目前国内的镜像有:
https://packagist.laravel-china.org https://packagist.phpcomposer.com
全局配置:
composer config -g repo.packagist composer https://packagist.phpcomposer.com
或者直接修改全局配置文件
步骤:
1查看composer的全局配置文件:composer config -l -g
最后一行的[home] C:/Users/lichihua/AppData/Roaming/Composer就是配置文件的路径 找到这个路径下面的config.json文件(或者在项目composer.json下加入这段内容
).将内容手动改为:
{ "config": { }, "repositories": [ {"type": "composer", "url": "http://pkg.phpcomposer.com/repo/packagist/"}, {"packagist": false} ] }
将url里的地址替换为中国的地址如:https://packagist.phpcomposer.com
当然也可以在进入当前项目的目录使用composer config repo.packagist composer https://packagist.phpcomposer.com 命令
composer config repo.packagist composer https://packagist.phpcomposer.com
他也会自动在当前项目的
composer.json
文件下自动生成:
"repositories": { "packagist": { "type": "composer", "url": "https://packagist.phpcomposer.com" } }
composer.json 中的各个属性字段详解
重要:
requires字段:
定义要下载的依赖包
"require": { "php": ">=5.6.4", "chumper/zipper": "^1.0", "doctrine/dbal": "^2.5", "fideloper/proxy": "^3.3", "fzaninotto/faker": "~1.4", "guzzlehttp/guzzle": "^6.3", "imagine/imagine": "^0.7.1", "laravel/framework": "5.4.*", "laravel/socialite": "^3.0", "laravel/tinker": "~1.0", "omnipay/paypal": "^2.6", "omnipay/stripe": "^2.4", "pda/pheanstalk": "^3.1", "sentry/sentry-laravel": "^0.8.0", "symfony/event-dispatcher": "^2.8", "vebto-server": "dev-master" },
autoload字段:
当我们想让composer帮我们自动加载我们自己定义的类的时候
"autoload": { "psr-4": { "AppBundle\\\\": "src/AppBundle" }, "classmap": [ "app/AppKernel.php", "app/AppCache.php" ] },
然后执行composer update 执行成功就能自动加载了
注意:每次更新完composer.json后,必须执行composer update后才会生效。
PSR-0自动加载 此规范已经废掉了但是composer还兼容此规范
PSR-1基本代码规范
PSR-2代码样式 算是对PSR-1的补充吧
PSR-3日志接口
PSR-4 自动加载
更多的PSR规范... 及例子 和笔记
命名空间的申明及使用
在任何一个没有声明命名空间的文件中,使用的命名空间都是相对于根命名空间\\的,比如是使用Exception
就不需要加反斜杠。
如果此文件用namespace指定了当前的命名空间,在使用Exception
的时候如果不加反斜杠就是相对于当前的命名空间。
但是申明的时候语法规则默认为你加了一个反斜杠,后面的被认为是一个常量。所以定义命名空间不能以\\开头
限定名称、非限定名称、完全限定名称
其实可以把这三种名称类比为文件名(例如 comment.php)、相对路径名(例如 ./article/comment.php)、绝对路径名(例如 /blog/article/comment.php),这样可能会更容易理解
//创建空间Blog namespace Blog; class Comment { } //非限定名称,表示当前Blog空间 //这个调用将被解析成 Blog\\Comment(); $blog_comment = new Comment(); //限定名称,表示相对于Blog空间 //这个调用将被解析成 Blog\\Article\\Comment(); $article_comment = new Article\\Comment(); //类前面没有反斜杆\\ //完全限定名称,表示绝对于Blog空间 //这个调用将被解析成 Blog\\Comment(); $article_comment = new \\Blog\\Comment(); //类前面有反斜杆\\ //完全限定名称,表示绝对于Blog空间 //这个调用将被解析成 Blog\\Article\\Comment(); $article_comment = new \\Blog\\Article\\Comment(); //类前面有反斜杆\\
自动加载说明:
注意:
1、composer.json文件是不能包含任何注释的,会报错 composer加载流程
2、声明的命名空间、文件夹与类文件及类名大小写要一致,否则在linux会报错!!
3、下载的依赖包直接可以使用(如include “vendor/autoload.php”;new PHPExcel();) ,不需要我们在json里定义autoload 自动加载,当我们需要自动加载自定义类的时候autoload就排上用场了
conposer自动加载有四种方式:PSR-0、 PSR-4、 file、 classmap
{ "name" : "dash/test", "require": { "swiftmailer/swiftmailer": "5.*.*@dev", "phpoffice/phpexcel": "dev-master" }, "repositories": { "packagist": { "type": "composer", "url": "https://packagist.phpcomposer.com" } }, #自动加载格式: root命名空间:起始路径 命名空间的申明应该以\\\\结束 如果不加\\\\Foo可以与FooBar匹配 加上Foo\\\\ 和 FooBar\\\\ 就会被区分开啦 "autoload":{ "psr-0":{ "church\\\\":"./src/", # 简单理解将./src路径替换为church 所以 src里的类文件必须有namespace church #use church\\testClass, 那就对应src/church/testClass.php. #use church\\test\\testClass, 那就对应src/church/test/testClass.php "Test\\\\" :"core/", #composer update后 ./vender/composer/autoload_psr4.php的 数组里会多出\'Test\\\\\' => array($baseDir . \'/core\'), "UniqueGlobalClass": "" # 这个类的php源文件也位于包的根目录 }, "psr-4":{ "church\\\\":"./src/", # use church\\TestClass, 那就对应src/testClass.php. # use church\\Test\\TestClass, 那就对应src/test/testClass.php # "Dash\\\\":["extra/","library/"], #多个目录中一个相同的(命名空间)前缀 psr-0 也适用 "":"any/" #任何命名空间(即实例化类时其他地方未定义,那么就会进入any查找) 设置一个目录作为任何命名空间的备用目录psr-0也适用 }, "files":[ "src/MyLibrary/functions.php" #一般用来自动加载函数、配置等非类文件 ], #当Composer开始安装和更新扩展的时候,会根据composer.json里的这个autoload告诉的方式classmap, #来遍历src、lib目录然后将里面的类文件和其路径一一对应,存放到vendor/composer/autoload_classmap.php内 #src/文件下必须有文件并且定义了类才会被加载到classmap "classmap":[ "src/", "lib/" ] } }
目录及文件结构
any classmap |--somethingClassmap.php core |--ClassTestXXX.php |--Test |--ClassTest.php |--A |--B |--C |-CustomClass.php index |--index.php lib |--somethingLib.php library |--A |--Test.php src |--Something.php |--somthingSrc.php |--A |--B |--C |--CustomeClass.php vendor composer.json #autoload_classmap.php return array( \'A\' => $baseDir . \'/src/somthingSrc.php\', //class A{}|$a=new A(); \'A\\\\somethingLib\' => $baseDir . \'/lib/somethingLib.php\', //namespace A; class somethingLib{}|$b=new \\A\\somethingLib(); \'Something\' => $baseDir . \'/src/Something.php\', //class Something{}|$c=new Something(); \'classmap\\\\somethingClassmap\' => $baseDir . \'/classmap/somethingClassmap.php\', //namespace classmap; class somethingClassmap{}|$d=new \\classmap\\somethingClassmap(); ); #autoload_files.php return array( \'2c102faa651ef8ea5874edb585946bce\' => $vendorDir . \'/swiftmailer/swiftmailer/lib/swift_required.php\',// 依赖包里的 \'504600fb8804f6fa5cfe80df6c85f147\' => $baseDir . \'/src/MyLibrary/functions.php\', //有这个文件的话就直接加载了 ); #autoload_namespaces.php return array( \'church\\\\\' => array($baseDir . \'/src\'), \'UniqueGlobalClass\' => array($baseDir . \'/\'), \'Test\\\\\' => array($baseDir . \'/core\'), \'PHPExcel\' => array($vendorDir . \'/phpoffice/phpexcel/Classes\'), ); #new \\church\\XXOO(); 对应文件/src/church\\XXOO.php的XXOO类 且声明 namespace church; class XXOO{} #new \\Test\\ClassTest();对应文件 \\core\\Test\\ClassTest.php的ClassTest类 且类中申明 namespace Test; #new Test\\A\\B\\C\\CustomClass(); 对应文件\\core\\Test\\A\\B\\C\\CustomClass.php的CustomCLass类 且申明 namespace Test\\A\\B\\C; #autoload_psr4.php return array( \'church\\\\\' => array($baseDir . \'/src\'), \'Dash\\\\\' => array($baseDir . \'/extra\', $baseDir . \'/library\'), \'\' => array($baseDir . \'/any\'), ); #/src/church.php 的 namespace church;class XXOO{} #调用文件(必须有include "../vendor/autoload.php"; 这里的都将省略): #index.php(未定义命名空间) new \\church\\XXOO();或者new church\\XXOO();都可以 #index2.php(定义了命名空间) 必须new\\church\\XXOO(); #new Dash\\A\\B\\C\\CustomClass(); 对应文件\\library(或者extra)\\A\\B\\C\\CustomClass.php的CustomCLass类 且申明 namespace Dash\\A\\B\\C; #new A\\Test(); 对应文件\\any\\A\\Test.php 且申明namespace A;
总结:
PSR-0与PSR-4自动加载格式: root命名空间:起始路径
"psr-0|4":{ "root命名空间\\\\":"起始路径", },
PSR-0:
use root命名空间[\\额外路径]\\类名 <==> 对应文件路径:起始路径+root命名空间 + [额外路径] + 类文件(必须与类名一致)
new \\root命名空间[\\额外路径]\\类名() <==> 映射的类:起始路径+root命名空间 + [额外路径] + 类文件(必须与类名一致)下的类名 且类名必须声明 namespace root命名空间[\\额外路径
PSR-4:
use root命名空间[\\额外路径]\\类名 <==> 对应文件路径:起始路径+ [额外路径] + 类文件(必须与类名一致)
new \\root命名空间[\\额外路径]\\类名() <==> 映射的类:起始路径+ [额外路径] + 类文件(必须与类名一致)下的类名 且类名必须声明 namespace root命名空间[\\额外路径
psr-4比psr-0路径更简洁
composer只是自动加载定义在autoload中的没有require类文件 要想成功实例化类 加载的类文件必须 申明完整的命名空间
如果在实例化类的当前文件为申明命名空间 那么以\\开头或者不以\\开头都是可以的 否则必须以\\开头(前提是没有use而直接实例化哦)
关于Foo(root命名空间)会匹配到FooBar的情况?
----------------------------------------------------------------------------------------------------------over------------------------------------------------------------------------------------------------------
如果:要把项目打包成公共包发布,那么这些还是需要写上的否则这里的所有字段都是可选的{
"name": "topthink/thinkphp",// 包(该项目)的名字 以 / 分隔。包的所有者(一般都用github名)/包名(很多人会用Github的代码库名称来命名方便搜索) "description": "the ThinkPHP Framework",//简洁项目描述 (详细可以写在README.md文件里) "type": "framework", "keywords": ["framework","thinkphp","ORM"],//关键词的值是一个字符串数组,在发布成公用库的是时候,作为元数据信息,有利于包的搜索和发现 "homepage": "http://thinkphp.cn/", //主页,可以放你想放的任何页面地址 "license": "Apache2",//如果你决定将包公开发布,那么记得选择一个合适的许可证。这样别的程序员在引用包的时候,通过查看许可证,确保没有法律上的问题 "authors": [ { "name": "liu21st", "email": "liu21st@gmail.com" } ],//发布该项目的作者信息 // 依赖管理 "require": { "php": ">=5.3.0", //改项目的最低php版本为5.3
"ext-mbstring": "*", //依赖php的mbstring扩展
"swiftmailer/swiftmailer": "4.3.*@dev",// 报名/版本 这里表示该项目依赖于swiftmailer的5、4.3.0~4.3.*的开发版本 "phpoffice/phpexcel": "dev-master" //该项目依赖phpexcel的dev-maser版本 }, "minimum-stability": "dev"//来告诉Composer当前开发的项目的依赖要求的包的全局稳定性级别,它的值包括:dev、alpha、beta、RC、stable,stable是默认值 //有些包依赖只会在开发过程中使用,正式发布的程序不需要这些包定义在这里 "require-dev": { "codeception/codeception": "2.0.0 " } }
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 包”。
1、name
包的名字。由供应方(vendor)名和项目名组成,用 / 分隔。斜杆前面部分,代表包的所有者
在发布包的时候需要填。
2、description
对包的一个简短描述,通常是一行的长度。
在发布包的时候需要填。
3、version
包的版本。
格式必须是 X.Y.Z,选择性后缀:-dev、-alphaN、-betaN、-RCN。
4、type
包的类型,默认为 library。
包类型用于定制安装逻辑。如果你的包的安装需要一些特殊的逻辑,你可以定义一个定制的类型。它可以是一个 symfony-bundle 的类型,或者 wordpress-plugin,或者 typo3-module。这些类型将被特定的项目所用,它们将提供安装器来安装这些类型的包。
Composer 支持 3 种类型:
①library:默认值。它将复制文件到 vendor 目录。
②project:它表示这是个项目,而不是库。比如像 Symfony 标准版这种应用。
③metapackage:一个含有依赖的空包,能触发安装,但不包含文件,不会向文件系统写任何东西。
composer-install:为其他的定制类型的包提供安装器的包。
5、keywords
一个与包相关的关键词数组。用于包的搜索和过滤。
可选。
6、homepage
项目的网站 URL。
可选。
7、time
版本发布时间。必须是 YYYY-MM-DD 或 YYYY-MM-DD HH:MM:SS 格式。
可选。
8、license
包的许可证。可以是字符串或字符串数组。
可选,但强烈建议加上。
9、authors
包的作者。是个对象数组。
每个 author 对象有这些属性:
name:作者名字
email:作者邮箱
homepage:作者网站 URL
role:作者在项目中的角色(如:developer 或 translator)
10、support
各种关于该项目如何获取支持的信息。包含这些属性:
email:获取支持的邮箱
issues:问题跟踪的 URL
forum:论坛的 URL
wiki:Wiki 的 URL
irc:IRC 的频道
source:查看或下载源码的 URL
可选。
11、Package links
依赖包的映射表,由包名映射版本约束。如:
{ "require": { "monolog/monolog": "1.0.*" } }
列出包所依赖的包。除非这些依赖已经存在,否则这个包不会被安装。
版本规则:
使用 ~ 约束符锁定小版本的方式 ~1.1.15 是指>= 1.1.15 并且 < 1.2.0的版本 ~1.1 表示可以为 大于等于 1.1 的任何版本,比如 1.1.0、1.2.0、1.3.5 、1.99.9999、 1.9999.999999 都可以安装,但是不能安装 2.0.0, 使用^ 锁定不允许变的第一位,即大版本不能变。 ^1.2 表示任意大于等于 1.2 的 1.x.x 版本,但是小于2.xx。比如 1.2.0、1.2.1、1.3.0、1.9.99999 等。只要前面的 1 并且大于 ^ 后面指定的 1.2 都满足条件。 使用>=锁定版本范围 有时候我们的使用场景要求只能安装某些版本范围内的时候,可以使用 >、<、>=、<=、| 这些符号来组合,比如:>= 1.3 <1.6、>=1.3 | >=1.7 、3.0|4.0 等。这样的使用场景并不多,根据你的情况来调整用法就好。如果在composer中有多个条件可以使用,隔开,相当于and 例如 >1.3,即只要比1.3版本大即可,如1.4,1.4.9 ,2.0,3.0,4.9.1等 = 使用具体版本号 使用 =1.2.34 或者 1.2.34 都是指定了具体的版本号, composer 不会考虑检查新版本来安装。
(2)require-dev(root-only)
列出开发这个包(或跑测试等等)所依赖的包。在使用 install 命令时,只有带上 “–dev” 参数才能安装 dev 包。在使用 update 命令时,带上 “–no-dev” 则不更新。
(3)conflict
列出包会和哪些包发生冲突。它们将不被允许和你的包一起安装。如果约束了版本,则只会针对特定的版本。
(4)replace
列出哪些包要被这个包替代。
(5)provide
这个包所推荐的包列表。这个对公共接口最有用,一个包可以依赖一个虚拟的 logger 包,而实现 logger 接口的库可以放到 provide 字段中。
12、suggest
建议一些能让这个包工作的更好或得到增强的包列表。这些信息只在包安装完成时给出,暗示用户可以添加更多包,虽然不是必须要安装的。
格式是,包名映射文字说明,如:
提供给 PHP autoloader 的自动加载映射。
目前支持的有:PSR-0 自动加载规范,classmap 生成器,还有 files。
PSR-0 是比较推荐的,因为它的优秀的扩展性(在添加新的类的适合,不需要重新生成自动加载器)。
(1)PSR-0
在 psr-0 键名下,定义一个命名空间到路径的映射表,相对于包的根目录。注意,这也同样支持 PEAR-style 的没有命名空间的风格。
请注意命名空间的声明得以 \\\\ 结尾,确保自动加载器正确响应。
PSR-0 的引用可以在安装或更新时生成的文件中查看:
vendor/composer/autoload_namespaces.php
例子:
{ "autoload": { "psr-0": { "Monolog\\\\": "src/", "Vendor\\\\Namespace\\\\": "src/", "Vendor_Namespace_": "src/" } } }
如果你需要在多个目录里查找同一个前缀的命名空间,你可以用数组,如:
{ "autoload": { "psr-0": { "Monolog\\\\": ["src/", "lib/"] } } }
PSR-0 风格并不局限于加载命名空间的声明的东西,也可以用于类这个层级。当库中只有一个在全局命名空间中的类时,这种方式就能用上。比如你有个 PHP 源文件放在项目的根目录,你可以这样声明:
{ "autoload": { "psr-0": { "UniqueGlobalClass": "" } } }
如果你有个目录下全是用命名空间组织的,你可以用空前缀:
{ "autoload": { "psr-0": { "": "src/" } } }
(2)Classmap
classmap 的引用可以在安装或更新时生成的文件中查看:
vendor/composer/autoload_classmap.php
类映射表是通过扫描指定的目录或文件下的所有的 .php 和 .inc 文件生成的。
你可以给任何不支持 PSR-0 的库用 classmap 生成器实现自动加载。配置上只要指定类所在的目录或文件即可:
{ "autoload": { "classmap": ["src/", "lib/", "Something.php"] } }
(3)files
如果你确定需要在任何请求中都加载某些文件,你可以使用 files 自动加载机制。对于那些包中有些 PHP 函数但不能自动加载时特别有用。例如:
{ "autoload": { "files": ["src/MyLibrary/functions.php"] } }
开发环境运行测试组件所需的类不应包含在上面主要的自动加载规则中,以避免在生产环境中以及当其他人将包作为依赖项使用时污染自动加载程序。
因此,为您的单元测试依赖一个专用的路径并将其添加到autoload-dev部分是一个好主意如:
"autoload-dev": { "psr-4": { "MyLibrary\\\\Tests\\\\": "tests/" } }
15、include-path
(将被弃用,它的功能由 autoload 代替。其实就是设置 include_path,可选)
16、target-dir
指定安装目标路径。
如果包的根目录是在命名空间下,自动加载就不正确了,所以才有 target-dir 来解决这个问题。
Symfony 就是个例子。它由很多组件包组成。Yaml 组件是在
命名空间下的,它的根目录是 Yaml 目录。要让自动加载正常工作,我们要确保它不是安装在
vendor/symfony/yaml
,而是安装在
vendor/symfony/yaml/Symfony/Component/Yaml
,这样自动加载器才能从 vendor/symfony/yaml 加载它。
所以要定义 target-dir 如下:
{ "autoload": { "psr-0": { "Symfony\\\\Component\\\\Yaml\\\\": "" } }, "target-dir": "Symfony/Component/Yaml" }
17、minimum-stability(root-only)
定义根据稳定性如何过滤包。默认是 stable,如果你信赖一个 dev 包,你需要指明。
18、prefer-stable(root-only)
如果开启,Composer 会在稳定包和不稳定包中选择前者。
19、repositories(root-only)
定制包的仓库地址。
默认的,Composer 只使用 Packagist 仓库。通过指定仓库地址,你可以从任何地方获取包。
仓库不能递归。你只能将它们添加到主的 composer.json 中。所依赖包中 composer.json 文件中的仓库定义是被忽略的。
支持的仓库的类型有:
(1)composer
composer 仓库通过网络提供 packages.json 文件,它包含一个 composer.json 对象的列表,还有额外的 dist 或 source 信息。packages.json 文件通过 PHP 流加载。
(2)vcs
版本控制系统仓库,如:git、svn、hg。
(3)pear
通过它,你可以导入任何 pear 仓库到你的项目中。
(4)package
如果你依赖一个不支持 composer 的项目,你可以定义一个 package 类型的仓库,然后将 composer.json 对象直接写入。
完整的例子:
{ "repositories": [ { "type": "composer", "url": "http://packages.example.com" }, { "type": "composer", "url": "https://packages.example.com", "options": { "ssl": { "verify_peer": "true" } } }, { "type": "vcs", "url": "https://github.com/Seldaek/monolog" }, { "type": "pear", "url": "http://pear2.php.net" }, { "type": "package", "package": { "name": "smarty/smarty", "version": "3.1.7", "dist": { "url": "http://www.smarty.net/files/Smarty-3.1.7.zip", "type": "zip" }, "source": { "url": "http://smarty-php.googlecode.com/svn/", "type": "svn", "reference": "tags/Smarty_3_1_7/distribution/" } } } ] }
20、config(root-only)
针对项目的一些配置。
process-timeout: 默认 300 秒,Composer 进程执行超时时间; use-include-path: 默认 false,如果是 true,Composer 自动加载器也会到 PHP 的 include_path 中查找; preferred-install: 默认 auto,设置 Composer 安装方式; github-protocols: 默认 [“git”, “https”],设置与 github 通信协议; github-oauth: 设置 oauth; vendor-dir: 默认 vendor,你可以换成别的; bin-dir: 默认 vendor/bin,如果项目有二进制文件,会链接到这; cache-dir: 默认 $home/cache,存放 Composer 运行时产生的缓存; cache-files-dir: 默认 $cache-dir/files,存放包的 zip 文件; cache-repo-dir: 默认 $cache-dir/repo,存放仓库元数据; cache-vcs-dir: 默认 $cache-dir/vcs,存放 vcs 克隆; cache-files-ttl: 默认六个月,缓存的过期时间; cache-files-maxsize: 默认 300M; notify-no-install: 默认 true,从仓库安装包会有个通知,可以关掉; discard-changes: 默认false,如何处理脏的更新;
21、scripts(root-only)
Composer 允许你在安装进程中安装钩子脚本,钩子是基于事件的;
22、extra
供 scripts 消费的额外数据;
23、bin
指定哪些文件必须被当做二进制文件处理的;
24、archive
设置创建包时的选项,exclude 属性可以设置排除哪些目录,例如:
{ "archive": { "exclude": ["/foo/bar", "baz", "/*.test", "!/foo/bar/baz"] } }
25、 abandoned
指示是否已放弃此包。
它可以是布尔值,也可以是指向推荐替代方法的包名/URL。例:
"abandoned": true //表示此包已弃用。 或者: "abandoned": "monolog/monolog" //表示此包已被抛弃,推荐的替代方案是monolog/monolog。
默认值为false。
可选的。
非数字分支名的正则表达式模式列表(例如。“最新的”之类的),这将不会作为特性分支处理。这是一个字符串数组。
如果您有非数字的分支名称,例如“最新的”、“当前的”、“最新稳定的”或其他看起来不像版本号的名称,那么Composer将处理这些分支作为特性分支。这意味着它搜索父分支,这些分支看起来像一个版本,或者以特殊分支(如主分支)结束,根包版本号成为父分支的版本,或者至少是主分支的版本。
要将非数字命名分支作为版本处理,而不是搜索具有有效版本或特殊分支名称(如master)的父分支,您可以为分支名称设置模式,这些模式应该作为开发版本分支处理。
当您使用“self”进行依赖时,这非常有用。,这样就不是dev-master,而是安装了相同的分支(在示例中:最新测试)。
例子:如果您有一个测试分支,它在测试阶段进行了大量维护,并部署到登台环境中,那么composer show -s通常会为您提供versions : * dev-master。
如果您配置latest-.*作为非特征分支的模式如下:
{ "non-feature-branches": ["latest-.*"] }
这时composer show -s
会给你 versions : * dev-latest-testing
.
Optional.
以上是关于composer的主要内容,如果未能解决你的问题,请参考以下文章
Azure 机器人微软Azure Bot 编辑器系列 : 机器人/用户提问回答模式,机器人从API获取响应并组织答案 (The Bot Framework Composer tutorial(代码片段
在下面的代码片段中的剩余 ='passthrough' 处的代码中出现语法错误