引出
在實際使用中經常會有這樣的需求, 多個PHP項目中用到了同一套代碼, 如果靠複製粘貼的話, 不光代碼不好維護, 而且同步起來也麻煩.
但是可以用 PHP 的包管理呀, composer. 那新的問題來了, 我們自己私人的包, 並不想開源出去, 怎麼辦呢?
來了, 利用gitlab github gitee 等管理自己的私有 composer 包. 這三個都是 git 管理工具, 使用起來都是一模一樣的流程, 我就以訪問速度比較快的gitee來舉例.
發佈 composer 包
首先創建一個項目, 然後在src路徑下放自己的源代碼, 當然其他路徑或者跟路徑都可以. 然後在項目的跟路徑下新建composer.json文件(請自行將下面的註釋去掉):
{
// 包的名字, 在之後其他項目引入`require`的時候,用的就是這個
"name": "hujingnb/composer_demo",
// 包的描述信息
"description": "composer test",
// 包類型, 這裏指定爲 庫
"type": "library",
// 作者信息, 可以有多個, 沒有也行
"authors": [
{
"name": "hujingnb",
"email": "[email protected]"
}
],
// 在這裏如果用到了其他的包, 也可以引進來
"require": {},
// 設置自動加載機制
"autoload": {
"psr-4": {
"hujingnb\\": "src/"
}
}
}
當然, 如果嫌麻煩, 可以在跟路徑下直接運行composer init 跟着它的提示將信息填進去就行了.
然後我在src路徑下創建了一個測試文件MyUtil.php:
<?php
/**
* 測試, 隨便寫兩個
* @author hujing
* @date 2020/6/18
*/
// 這裏的命名空間要和 composer 中定義的自動加載機制相對應
namespace hujingnb;
class MyUtil{
public static function echoTest(){
echo 'test';
}
}
當然, 因爲要提交git嘛, gitignore 當然是少不了的.
現在我的項目結構如下:
這個時候先別急着提交, 可以先測試一下. 直接在跟路徑下執行composer install . 執行之後, 你就會發現跟路徑多了一個 vendor 包, 寫個 test 測試一下. 現在的結構如下:
Test.php 文件中簡單調用了一下測試的方法(當然, 在真實的項目中也可以這樣搞, 畢竟你的包寫完也是需要測試的嘛):
<?php
require_once __DIR__.'/../vendor/autoload.php';
\hujingnb\MyUtil::echoTest();
echo PHP_EOL;
運行一下, 一切正常, 把項目提交上去, 因爲是私人用嘛, 提一個私有項目就好啦. 之後這個包作爲一個單獨的項目進行維護就好了.
在項目中引入私有包
另外建一個項目, 用來測試引入私有包. composer.json 如下(請自行刪除註釋):
{
"name": "root/composer_require_demo",
"authors": [
{
"name": "hujingnb",
"email": "[email protected]"
}
],
"require": {
// 指定引入的包名稱, 這個名稱就是上面包的 "name"屬性, 後邊指定引入 master 分之
"hujingnb/composer_demo": "dev-master"
},
"repositories": [
// 將包源換成阿里雲的, 速度快一些
{
"type": "composer",
"url": "https://mirrors.aliyun.com/composer/"
},
// 禁用官方請求, 否則慢的要死, 甚至超時
{
"packagist": false
},
// 將自己的項目 git 連接放進來
{
"type": "git",
"url": "https://gitee.com/hujingnb/composer_demo.git"
}
],
"config": {
// 開啓 http 請求, 當然, 如果上面的 git 使用的是 ssh 的話, 這裏可以不加. 不過需要配置 ssh, 請自行谷歌
"secure-http": false
}
}
git 鏈接哪裏有, 這裏:
好了, 執行 composer install 命令安裝吧. 因爲使用了 http 請求, 中間會要求輸入用戶名和密碼, 直接輸入就行. 安裝之後就是這樣了:
看vendor 的結構, 它其實就是直接將上面的項目 clone 進來了.
現在試驗一下更新功能, 將第一個項目進行更新點並提交, 本項目中執行composer update 或者 composer update hujingnb/composer_demo 只更新這一個包. 查看後確實更到了最新, 嗯嗯沒得問題.
好, 是不是很簡單呀.
最後的最後, 有沒有發現點什麼? 第二個項目的composer.json文件和第一個項目基本沒什麼區別嘛, 而且在 require 的時候, 使用的是"name"屬性, 在第二個項目中也有"name", 那是不是意味着, 第二個項目也可以作爲包被導入啊? 我試了一下, 確實可以. 所以, 每一個composer項目, 既引入了其他項目, 同時也可以被其他項目引入. 嗯嗯, 666.
以後就可以告別代碼的複製粘貼, 將私有包通過git 管理工具統一管理啦.