PHP开发者必须了解的包依赖管理工具：Composer

Composer是一个十分盛行的PHP包依靠管理东西,现已替代PEAR包管理器,关于PHP开发者来说把握Composer是有必要的.

关于运用者来说Composer十分的简略,经过简略的一条指令将需求的代码包下载到vendor目录下,然后开发者就能够引进包并运用了.
其间的关键在于你项目界说的composer.json,能够界说项目需求依靠的包(或许有多个),而依靠的包或许又依靠其他的包(这便是组件的优点),这些都不用你烦心,Composer会主动下载你需求的一切,一切在于composer.json的界说.
Composer关于运用者来说是很透明,但是其背后的理念仍是需求了解一下的,其的诞生也不是偶然的,得益于Github的快速开展,PHP言语也越来越现代化,显得更高大上了.
为了了解Composer,先大概了解下其结构:
Composer的结构
Composer指令行东西:
这个了解就比较简略了,经过运用者界说的Composer.json去下载你需求的代码,假设只是简略的运用Composer,那么把握一些详细指令就完全能够了
Autoloading代码加载器:
经过Composer,开发者能够经过多种办法去运用,而其间的关键在于PHP的命名空间概念,以及PSR-4规范的开展,Composer只是依据这二者开发了一个代码主动加载器
Github:
有了Github,PHP开发人员能够将开源的代码保管在这上面,而Composer的开展源于Github,Composer本质上便是将Github上的代码下载到本地.
Packagist:
关于运用者来说运用的是Composer的指令行东西,那么指令行东西怎样知道有多少包能够被用户运用呢,这首要便是依靠于Packagist,Packagist是Composer首要的一个包信息存储库,包开发者将详细代码保管到Github上,将包信息提交到Packagist上,这样运用者就能够经过Composer去运用.
Composer依据本地界说的composer.json信息去查询Packagist,Packagist依据Composer.json/Package.json信息解析,终究对应到github库房,Composer终究下载代码的时分还要依靠于Github库房上的Composer.json,这儿涉及到三种类型的composer.json,含义是不一样的.
Composer.json:
这是Composer的核心,是Composer的规矩,上面也提到了三种类型的Composer.json,在运用的时分一定要注意区分,我初学的时分就总是搞乱.
Composer指令行东西
composerinit
运用者能够在自己的项目下创立composer.json以便界说你项意图依靠包,也能够经过composerinit交互式的创立composer.json.
composerinstall
应该是最常用的指令,composer会依据本地的composer.json装置包,将下载的包放入项目下的vendor目录下,一起将装置时分的包版别信息放入到composer.lock,以便锁定版别.
其实在install的时分,假设发现composer.lock版别和目前vendor目录下的代码版别是一致的,则Composer会什么也不做,composer.lock的意图便是让你安心在目前这个版别下工作,而不获取最新版别的包.
composerupdate
那么怎么更新composer.lock以便获取到最新版别的包呢?经过这个指令即可更新最新版别的包
composerconfig
这个指令仍是主张了解下,大局的配置保存在COMPOSER_HOME/config.json,非大局的配置信息则存储在本项目目录下.
composerconfig–list-g
composerconfig-gnotify-on-installfalse
composerglobalconfigbin-dir–absolute
composercreate-project
这个指令不常用,但是个人觉得仍是很重要的,运用一般的install指令是将项目所有的依靠包下载到本项目vendor目录下.而经过这个指令则是将所有的代码及其依靠的包放到一个目录下,相当于履行了一个gitclone指令,一般是包的开发者或许为了修正bug会运用该指令.
composerglobal
这是一个大局的装置指令,它允许你在COMPOSER_HOME目录下履行Composer的指令,比方install,update.当然你的COMPOSER_HOME要在$PATH环境下.
比方履行composerglobalrequirefabpot/php-cs-fixer,现在php-cs-fixer指令行能够大局运转了,如果稍后想更新它,只需求运转composerglobalupdate
composerdump-autoload
当你修改项目下的composer.json的文件,并不一定要运转composerupdate指令进行更新,有的时分能够运用该指令来更新加载器,比方你要引证本地自界说的包(不是来自于packagist),后边会经过实践来阐明该指令.
composerrequire
假设手动或许交互式创立composer.json文件,能够直接运用该指令来装置包
composerrequirecerdic/css-tidy:1.5.2
composerrequire”ywdblog/phpcomposer:dev-master”
–prefer-source和–prefer-dist参数
–prefer-dist:关于安稳的包来说,一般Composer装置默许运用该参数,这也能加快装置,比方有或许直接从packagist装置了相应的包,而不用实践去Github上下载包.
–prefer-source:假设运用该参数,则会直接从Github上装置,装置包后vendor目录下还含有.git信息
composerrequire”ywdblog/phpcomposer:dev-master”–prefer-source
#在vendor/ywdblog/phpcomposer目录下含有.git信息
怎么给Composer添加代理
在国内运用Composer下载特别慢,能够经过二个办法进行加快
composerconfigrepo.packagistcomposer“https://packagist.phpcomposer.com“
修改composer.json
“repositories”:{
“packagist”:{
“type”:”composer”,
“url”:”https://packagist.phpcomposer.com”
}
}
Autoloading代码加载器
composer自身集成一个autoloader,支撑PSR-4,PSR-0,classmap,filesautoloading.
这儿经过一个比方来阐明经过Composer怎么引证classmap,files,本地契合PSR-4规范的代码
修改composer.json
“autoload”:{
“classmap”:[“othsrc/”,”classsrc.php”],
“files”:[“othsrc/filesrc.php”],
“psr-4”:{“FooBar”:”src”}}
composerdump-autoload
经过上述的操作,关于PSR-4来说同等注册了一个PSR-4autoloader(从FooBar命名空间)
假设不想运用Composer的autoloader,能够直接包含vendor/composer/autoload_*.php文件,配置自己的加载器.
详细的比方保管在github上,可参阅.
Repositories
关于Repositories,了解其不是有必要的,但是假设把握则更能了解Composer,关于Repositories,其间文文档和英文文档解释的很好,这儿也进行了一些摘抄.
基本概念
包:
Composer是一个依靠管理东西,它在本地装置一些资源包和包的描绘(比方包名称和对应的版别),比较重要的元数据描绘是dist和source,dist指向一个存档,该存档是对一个资源包的某个版别的数据进行的打包.source指向一个开发中的源,这通常是一个源代码库房(比方git)
资源库:
一个资源库是一个包的来历.它是一个packages/versions的列表.
Composer将检查所有你界说的repositories以找到项目需求的资源包(这句话很重要).
默许情况下现已将http://Packagist.org注册到Composer(或许了解为http://Packagist.org是Composer资源库默许的库房类型)
Composer资源库类型
Composer资源库包括四种类型,默许的是composer类型,也便是http://packagist.org所运用的资源类型.
它运用一个单一的packages.json文件,包含了所有的资源包元数据.当你将包发布到http://pckagist.org上,则默许系统会创立一个packages.json,不过我没有找到我的包对应的文件.
VCS资源库类型
{
“repositories”:[
{
“type”:”vcs”,
“url”:”https://github.com/ywdblog/phpcomposer”
}
],
“require”:{
“ywdblog/phpcomposer”:”dev-master”
}
}
当运转composerupdate的时分,Comoser实践上是从Github上下载包而不是从http://pckagist.org上下载.
别的假设需求运用Package资源库类型或许PEAR资源库类型,参阅官方文档即可,一般在composer.json中界说name、version特点即可.
Composer.json
在本文上面也多次提到了composer.json,比方你希望运用第三方包则需求在本地界说composer.json,Composer装置第三方包后,也会在第三方包目录下发现composer.json,那么这二者都叫composer.json,有什么区别呢?了解这十分的重要.
假设你在自己的项目下面界说一个composer.json,则这个包称之为ROOT包,这个composer.json界说你项目需求的条件(比方你的项目或许依靠一个第三方包).
composer.json中有些特点只能被ROOT包运用,比方config特点只在ROOT包中生效.
一个资源包是不是ROOT包,取决于它的上下文,比方你gitcloneywdblog/phpcomposer,则这时分本地phpcomposer目录便是ROOT包,假设你在本地phpcomposer目录下composerrequireywdblog/phpcomposer,则这时分你的项目phpcomposer便是ROOT包.
了解composer-schema.json可参阅该网址,Laravel作为一个老练的框架,其界说的composer.json十分经典
关于包的版别
当运用者在本地配置composer.json的时分,能够指定需求包的特定版别,Composer支撑从Github库房中下载Tag或许分支下的包.
关于Github上的Tag来说,Packagist会创立对应包的版别,它契合X.Y.Z,vX.Y.Z,X.Y.Z-包类型,便是说Github上尽管只有一个特定版别的包,但Composer支撑多种形式的引证办法,比方:
composerrequiremonolog/monolog1.0.0-RC1
composerrequiremonolog/monologv1.0.0-RC1
composerrequiremonolog/monolog1.0.*
composerrequiremonolog/monolog~1.10
关于Github上的分支来说,Packagist会创立对应包的版别,假设分支名看起来像一个版别,将创立{分支名}-dev的包版别号,如果分支名看起来不像一个版别号,它将会创立dev-{分支名}形式的版别号
总结:
了解Composer,最重要的是实践,最终也能理解PSR-4和命名空间,也能够测验将你的项目发布到http://pckagist.org上.