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命令行工具

composer init

使用者可以在自己的專案下建立composer.json以便定義你專案的依賴套件,也可以透過composer init互動式的建立composer.json.

composer install

應該是最常用的命令,composer會根據本地的composer.json安裝包,將下載的包放入項目下的vendor目錄下,同時將安裝時候的包版本信息放入到composer.lock,以便鎖定版本.

其實在install的時候,假如發現composer.lock版本和目前vendor目錄下的程式碼版本是一致的,則Composer會什麼也不做,composer .lock的目的是讓你安心在目前這個版本下工作,而不獲取最新版本的包.

composer update

那麼如何更新composer.lock以便獲取到最新版本的包呢?透過這個指令即可更新最新版本的套件

composer config

這個指令還是建議了解下,全域的設定保存在COMPOSER_HOME/config.json,非全域的設定資訊則儲存在本專案目錄下.

composer config --list -gcomposer config -g notify-on-install falsecomposer global config bin-dir --absolute

composer create-project

這個指令不常用,但是個人覺得還是很重要的,使用普通的install指令是將專案所有的依賴包下載到本專案vendor目錄下.而透過這個指令則是將所有的程式碼及其依賴的包放到一個目錄下,相當於執行了一個git clone命令,一般是包的開發者可能為了修復bug會使用該命令.

composer global

這是一個全域的安裝指令,它允許你在COMPOSER_HOME目錄下執行Composer的指令,例如install,update.當然你的COMPOSER_HOME要在$PATH環境下.

例如執行composer global require fabpot/php-cs-fixer,現在php-cs-fixer命令列可以全域運行了,如果稍後想更新它,只需要運行composer global update

composer dump-autoload

#當你修改專案下的composer.json的檔案,並不一定要執行composer update指令進行更新,有的時候可以使用該指令來更新載入器,例如你要引用本地自訂的套件(不是來自於packagist) ,後面會透過實作來說明該指令.

composer require

假如手動或互動式建立composer.json檔,可以直接使用該指令來安裝套件

#composer require  cerdic/css-tidy:1.5.2composer require "ywdblog/phpcomposer:dev-master"

–prefer-source和–prefer-dist參數

#–prefer-dist:對於穩定的套件來說,一般Composer安裝預設使用該參數,這也能加快安裝,例如有可能直接從packagist安裝了相應的包,而不用實際去Github上下載包.

–prefer -source:假如使用該參數,則會直接從Github上安裝,安裝套件後vendor目錄下還含有.git訊息

composer require "ywdblog/phpcomposer:dev-master" --prefer-source
#在vendor/ywdblog/phpcomposer目錄下含有.git信息

如何給Composer添加代理

在國內使用Composer下載特別慢,可以透過二方法進行加速

composer config repo.packagist composer “https://packagist.phpcomposer.com“

編輯composer.json

#"repositories": { "packagist": {      "type": "composer",      "url": "https://packagist.phpcomposer.com"
 }
}

Autoloading程式碼載入器

composer本身整合一個autoloader,支援PSR-4,PSR-0,classmap,files autoloading.

這裡透過一個範例來說明透過Composer如何引用classmap,files,本地符合PSR-4標準的程式碼

編輯composer.json

"autoload": {  "classmap": ["othsrc/","classsrc.php"],  "files": ["othsrc/filesrc .php"],  "psr-4": {"Foo\Bar\": "src"}
}

composer dump-autoload
透過上述的操作,對於PSR -4來說等同註冊了一個PSR-4 autoloader(從FooBar命名空間)

假如不想使用Composer的autoloader,可以直接包含vendor/composer/autoload_*.php檔案,配置自己的載入器.
具體的例子託管在github上,可參考.

Repositories

#關於Repositories,了解其不是必須的,但是假如掌握則更能理解Composer,對於Repositories,其中文文件和英文文件解釋的很好,這裡也進行了一些摘抄.

基本概念

#包:

Composer是一個依賴管理工具,它在本地安裝一些資源包和包的描述(例如包名稱和對應的版本),比較重要的元資料描述是dist和source,dist指向一個存檔,該存檔是對一個資源包的某個版本的資料進行的打包.source指向一個開發中的來源,這通常是一個原始碼倉庫(例如git)

資源庫:

一個資源庫是一個包的來源.它是一個packages/versions的列表.

Composer將查看所有你定義的repositories以找到專案需要的資源包(這句話很重要).

預設情況下已經將Packagist.org註冊到Composer(或理解為Packagist.org是Composer資源庫預設的倉庫類型)

Composer資源庫類型

Composer資源庫包含四種類型,預設的是composer類型,也就是packagist.org所使用的資源類型.

它使用一個單一的packages.json檔案,包含了所有的資源包元資料.當你將套件發佈到pckagist.org上,則預設系統會建立一個packages.json,不過我沒有找到我的包對應的文件.

VCS資源庫類型

假如你想構建一個私有的Composer私有資源庫類型,可以使用該類型,這裡舉一個例子,例如你在自己專案的composer.json定義如下,則就可以使用對應的Github上的程式碼了.

{    "repositories": [    {       "type": "vcs",        
           "url": "https://github.com/ywdblog/phpcomposer"    }    ],    "require": {        
           "ywdblog/phpcomposer": "dev-master"    } }

當執行composer update的時候,Comoser實際上是從Github上下載套件而不是從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包,取決於它的上下文,比如你git clone ywdblog/phpcomposer,則這時候本地phpcomposer目錄就是ROOT包,假如你在本地phpcomposer目錄下composer require ywdblog /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支援多種形式的引用方式,例如:

composer require monolog/monolog  1.0.0-RC1
composer require monolog/monolog  v1.0.0-RC1
composer require monolog/monolog  v1.0.0-RC1
composer require monolog/monolog  1.0.0-RC1
composer require monolog/monolog pos1.0.0.D.0er require monolog/monolog  ~1.10

對於Github上的分支來說,Packagist會創建對應包的版本,假如分支名看起來像一個版本,將創建{分支名}-dev的包版本編號,如果分支名看起來不像版本號,它將會建立dev-{分支名}形式的版本號碼

composer require monolog/monolog  master-dev
composer require monolog/monolog  master .x-dev

總結:

理解Composer,最重要的是實踐,最後也能明白PSR-4和命名空間,也可以嘗試將你的專案發佈到pckagist.org上.

###

以上是Composer的詳細介紹的詳細內容。更多資訊請關注PHP中文網其他相關文章！