原文:http://blog.jayxhj.com/2016/05/basic-composer-package-development/html
composer 是 PHP 的依賴管理工具,本篇文章就來講明如何構建一個包,並提交到 Packagist ,這樣別人就能夠方便地經過 composer 使用你的包了。前端
開發 composer 包有如下幾個步驟:git
安裝好 composer 後便可在本地運行 composer init
經過交互式命令行設置 composer.json 。github
下面介紹其中的幾個屬性,以及常規的設置:web
/
隔開,前面的爲供應商名字,後面爲包名,供應商表明 Packagist 網站爲開發者提供的惟一的名字,用來組織包以及防止命名衝突。因此提交時最好先訪問 https://packagist.org/packages/yourvendorname 將 url 中的 yourvendorname 替換爲你想要取的名字,若是頁面沒有 404 ,說明已經被註冊了。http://json-schema.org/ 上介紹了 JSON Schema 的定義以及各個語言對其各類功能的實現,有 validator 的實現,其中 JSON Schema Validator 是在線的驗證服務。其實最簡單的就是使用 composer validate composer.json
來驗證文件是不是有錯誤。json
這是我演示的設置 composer.json 的視頻api
以我開發的 單點登陸 SDK 爲例,此項目基於 Laravel ,實現了站點接入單點登陸系統的簡單接入,應用只需在服務端註冊並實現指定接口,便可接入 SSO 。composer
項目結構是典型的 MVC 結構,ide
1 |
.
└── geo
└── geosso
├── LICENSE
├── README.md
├── composer.json
└── src
├── Contracts
├── Http
│ ├── Controllers
│ ├── Middleware
│ └── Requests
├── ParamsBean
├── Providers
├── Support
└── config
12 directories |
LICENSE、README.md 及 composer.json 是運行 tree -d
以後手工添加上去的。函數
項目根目錄定義在 src 下,在 composer.json 中也有定義,這樣當 composer 加載這個包時就知道如何經過命名空間去解析文件路徑。
Http 目錄表明請求響應,之下的 Controllers 表示合法請求的控制器,Middleware 表明請求的第一道關卡,經過中間件去攔截請求,Requests 去獲取前端請求並對請求過濾。
Contracts 表明接口定義。ParamsBean 表明應用層與底層服務溝通時的參數封裝,經過 Bean 去獲取各個參數,而不是傳遞 array 使得調用一致,而且強制接口調用時作類型檢測,能夠很大程度上統一各層之間的參數傳遞。
Providers 表明 Laravel 的服務容器,經過服務容器,能夠註冊路由與配置,加載助手類,綁定接口與其實現。
Support 就是一些助手類,對經常使用的與邏輯無關的功能的封裝,config 表明應用本身的配置,經過 config 能夠方便地將配置設置並使用全局函數 config()
調用。
按照前面的步驟,一個包就有了基本的骨架,接下來就是上傳至 GitHub ,配置項目,集成持續集成服務,發佈開源項目許可證。
GitHub 初始化項目時能夠選擇生成 .gitignore 文件,選擇許可證,初始化 README.md 文件,切換至本地的項目目錄後,按以下步驟便可將目錄上傳至 GitHub:
1 |
>git init # 初始化倉庫 |
Packagist 爲 composer 默認獲取包元數據信息的地址,從 Packagist 獲取到元數據信息後,再從 GitHub 上拉取代碼。所以,當把你開發的包上傳至 GitHub 後還須要將其在 Packagist 註冊,這樣全世界的人都能經過 composer 去拉去你的代碼了。
提交至 Packagist 只需三個步驟:
自此,一個基本的包開發就結束了。經過 composer 來管理 PHP 的依賴,經過編寫 composer package 去擴展本身的類庫,經過引入其餘的類庫來填充本身的功能,就不用重複造輪子了。