徒手解剖composer，簡單瞭解其實現過程

「composer」？，相信不少作PHP工做的對他並不陌生，他是一個針對第三方庫管理工具，解決庫與庫之間的依賴關係等等等，例如一些yii、laravel等框架都搭載着composer來方便管理第三方包和自身的包，總之他是一個很牛逼的庫。牛逼在哪兒，爲何牛逼，且先不去談。

 

來看看官網，https://getcomposer.org/（外文社區）

http://www.phpcomposer.com/（中文鏡像），首先能夠看到一個很放縱的男人，在肆無忌憚的發揮着本身的靈感去創做東西，絕不爲其餘雜事擔憂（除過肢體，怎麼看都感受這我的好難受，在遭罪的樣子），這大概是composer所帶來的精妙之處。

除此以外，你還能夠看到其文檔、指南以及基本介紹和下載途徑等，關於這個composer的一些發展史，和發展背景及經常使用的以及大概的基本使用流程。

但我怎麼沒有看到他的工做原理呢？例如，composer install 、update 這些命令實際作了什麼工做呢，她能爲個人項目帶來哪些便利呢？我該怎麼接入他？  含糊不及，沒有人知道他在說些什麼。

日前，拿到了一個laravel的項目增添一些東西，其中涉及到一個驗證碼的問題，laravel內置並無驗證碼的相關庫，大多都是經過第三方引入或者是手寫的。

經過搜索獲得，有gregwar/captcha相關的庫能夠進行方便接入驗證碼，但是網上關於這個庫的使用介紹只有composer的使用方式，按理說我就只須要install一下,update一下，引入一下就能夠很方便的得以使用，卻還要糾結那麼久。

若是你是以上思惟，那麼恭喜你，你不太適合作程序員，缺乏了程序員與生俱來癖症，他讓你那麼作，你就那麼作嗎？它讓你執行shutdown -s 你也執行嗎？最起碼也是須要將composer的前因後果搞清楚以後再去享受他所帶來的便捷之處，否則只會被工具所矇蔽。

按照我以往的習性，是不會給我電腦裝一堆本身所不知道其在幹些什麼事情的軟件。都不知道他在幹什麼，何須安裝它浪費那麼一大塊兒內存呢？固然這句話不是說composer，composer相似於一個插件，只有運行時纔會去執行，不會常駐內存。

咱們繼續，關於安裝composer，使用composer，網上有不少更專業的文章文檔能夠供予你們參考。此文只介紹composer的簡單工做內容。

那麼，不安裝composer，不使用那一堆堆命令就不能引用第三方庫了嗎？答案是能夠的，但對於初探者來講，可能會處處碰壁。

咱們所須要瞭解到，composer是安裝在PHP之上的，不借助於apache、nginx等web服務器運行，來看看一個命令：

php composer.phar install

由此就能夠看出，他是藉助於PHP去運行他的一些東西。假設你沒有安裝PHP或者沒有設置PHP路徑爲全局變量，那麼你也是沒法進行使用的。

拆解命令獲得：

D:\php\php.exe composer.phar install

那麼這樣也是能夠執行的，其就是省去了精準到PHP程序所在目錄這個步驟。

那麼後面的composer.phar install 到底作了些什麼內容，怎麼作的呢？

官方是這樣解釋的，

接着前面的例子，這將會找到 monolog/monolog 的最新版本，並將它下載到 vendor 目錄。 這是一個慣例把第三方的代碼到一個指定的目錄 vendor。若是是 monolog 將會建立 vendor/monolog/monolog 目錄。

大概描述清楚了,就是自動去尋找對應版本下載並建立一些目錄作以配置，可他是怎麼作的呢？

咱們得對php 的參數作以簡單瞭解，簡單舉例。

#運行PHP代碼
php -r "echo 'hello oschina';"

#運行PHP文件
php -f "d:\work\test.php"   #須要在php.ini裏配置對應的目錄，不然沒權限。

#變相一下,能夠在本地直接執行遠程服務端寫好的代碼（從服務端脫下來在本地執行）
php -r "eval(file_get_contents("http://www.server.com/test.php"))"

#更加變相一下，如下僞代碼
http://server.com/install.php 內容以下

<?php
$version = parseParamGetVersion($_SERVER['QUERY_STRING']);
$rootPath = dirname(__FILE__).'/';
$packArray = getPackByVersion($version)->toArray();

foreach($packArray as $key=>$files){
    $packPath = $rootPath.'verdor/'.$key.'/';
    if(! is_dir($packPath)){
        mkdir($pathPath);
        foreach($files as $filename => $file){
            $fileContent = file_get_contents($file);//獲取最新包的內容
            file_put_contents($packPath.$filename);//寫入包的內容
        }
    }
}
?>

#那麼本地只須要執行，就實際將存在於網上上的某個包最新數據獲取而且規範的寫到了本地項目中。
php -r "eval('http://server.com/install.php')";
甚至能夠將上一條代碼保存到install.bat，直接雙擊運行。

或許有些人看到這裏會恍然大悟，原來是這麼回事。那麼composer的工做方式也是相似，只不過他比較專業規範一些，使用了不少標準，統一代碼。

大概瞭解事後，咱們繼續迴歸問題，解決圖形驗證碼的問題。

幸甚，gregwar/captcha的全部源代碼已經在github上公開，連接從官網獲取。直接將git上代碼下載下來。所獲得的是一個關於這個庫的實例demo和核心庫以及關於composer自動加載的json配置。

咱們將它直接複製到項目目錄中，習慣性的將它和其餘同類改爲一致的小寫命名。

以及寫入一個簡單的demo，居然無恥的報錯了。

很顯然，錯是應當的，由於當前項目加載的時候並不知道已經新增了一個庫，就算引用也沒有找到地方。

嘗試手工修改composer.json，

"psr-4": {
            "App\\": "app/",
            "Gregwar\\Captcha\\": "vendor/captcha/" //增長引用庫，路徑模仿樓上
        },

"require": {
        "php": ">=5.5.9",
        "laravel/framework": "5.2.*",
        "gregwar/captcha": "dev-master" //當前不是必須的，當前配置時給composer看的，用做版本對比。
        
    },

修改保存了以後依然報錯，沒有找到對應的類。這時候應該是很操蛋的狀況。由於你明明知道，你此時只須要執行 

php composer update

就完事了，可是仍然忍者痛去剖解。

使用手工排除法，一步步echo exit;

報錯很明確，找不到那個類，那麼咱們只須要找到一些咱們認爲應該加載類的地方去調試看是否加載上那個類就能夠得以解決。

首先來到vendor目錄中的autoload.php，增長調試語句。

當前已經執行到此處了，繼續往下。深刻到圖中所示的autoload_real.php中去看看。

很明顯，咱們能夠看到他加載4大類的加載文件。咱們的庫在psr4標準中，執行後，發現dump出來的庫不包含咱們的庫。繼續追溯到所在的文件中，autoload_psr4.php。

保持隊形，在數組尾部增長本身所須要使用的庫配置。

保存後，將其餘調試代碼屏蔽掉後。再次運行，發現咱們的驗證碼出來了。

這個過程也就是php composer update 的主要操做。

還有一些其餘的命令，最好是自行研究，此文再也不多說。

文前，曾問過一些朋友，不少對這個工具使用都是遊刃有餘，有的表現的非常瞭解，但當我問起原理時，他好像並不知道什麼。

更明確瞭解其工做原理，會讓本身的工做更有信心，更不會被質疑，最好不要讓本身幹了些什麼事情都不曉得，都在一天瞎折騰，不然有一天本身調試bug的時候遇到奇葩的問題，更是無從入手。

最後推薦到https://getcomposer.org/ composer 官網看看，文檔都很全，只不過英文不太好的人閱讀起來很比較痛苦，好比說是我。能夠經過中文入門後再經過其深刻。