laravel/framework “symfony/http-kernel”: “~3.3”,
symfony/http-kernel(3.3.13版本) “symfony/translation”: “~2.8|~3.0”,
symfony/http-kernel(3.4版本) “symfony/translation”: “~2.8|~3.0|~4.0”,
symfony/translation3.4版本:
public function __construct($locale, $formatter = null, $cacheDir = null, $debug = false)
而在4.0的時候加入了7.1的特性
public function __construct(?string $locale, MessageFormatterInterface $formatter = null, string $cacheDir = null, bool $debug = false)
我機器上的版本是PHP 7.0。所以導致了在composer升級的時候symfony/http-kernel也升級,帶來了symfony/translation升級到4.x,引入了PHP7.1的新特性。
解決方法
升級線上機器PHP版本是不可能的事情。于是我只能強制限定版本號。
直接在最上層我的項目中require symfony/translation,并且指定版本號。
"symfony/translation" : "3.3.13"
重新composer update 就可以了。
思考
這是一個典型的依賴包升級導致的業務應用出錯的案例。symfony/translation 從 3.3.13 升級到4.*,需要的PHP版本從7.0升級到7.1。這樣的升級,laravel/framework 版本 v5.5.21 是無感知的。
而我們看 laravel/framework v5.5.21 的(comopser.json)[https://github.com/laravel/framework/blob/v5.5.21/composer.json]
{
"name": "laravel/framework",
"description": "The Laravel Framework.",
...
"require": {
"php": ">=7.0",
"ext-mbstring": "*",
"ext-openssl": "*",
...
"symfony/http-kernel": "~3.3",
},
...
}
這里的 PHP >= 7.0 是不是格外扎眼,根本已經不靠譜了。
真正解決辦法
哈,其實這里并沒有結束。這個問題包版本依賴其實各個包都沒有問題。
其實這里有一個問題,我打包機器的PHP版本是7.1,但是線上機器是7.0.0,所以會導致這個問題。
其實composer比我們想象的更為強大。它會根據你當前機器的PHP版本,判斷你的所有依賴分別使用什么版本,在composer update的時候,會根據所有依賴的版本需求選擇一個最好的版本。
所以我把我的打包機器上的PHP切換成7.0,查看生成的composer.lock,里面的symfony/translation就限制到使用3.3.x版本 就不會出現這個問題了。
composer的正確使用姿勢
是否要將composer.lock加入到git庫
這個是我這次犯的一個錯誤,沒有將composer.lock進入版本庫,打包機器composer install的時候就相當于update操作了。對于業務來說,這個是不對的。業務要做的事情是保證業務穩定性,其實任何的庫依賴的升級,都需要經過業務的測試和驗證才能上線。所以,這里強烈建議在業務項目里面,將composer.lock強制加入git代碼庫中。
是否要使用自動升級
版本依賴的時候,使用~,^符號會在composer udpate的時候根據依賴包已經有的類庫。
我理解自動升級的機制有好也有壞處,這個就相當于把主動權(這里已經說的是update的主動權)放在哪里。作為一個基礎類庫,我當然希望你使用我的時候能相信我,我的每次版本升級都是兼容的,也不會引入bug。所以類庫是會希望你會使用自動升級。這樣我的一些bug修復,在你update的時候你就會自動下載并且修復了。
但是對于業務來說,業務穩定是死要求。一旦我update的時候,我使用了你的新下載的包,這個實際上就有可能引入一個bug。沒有經過完整的測試,是不應該做這種操作的。
但是實際上,我們是無法完全杜絕這個情況,比如你的一個lib包依賴了另外一個lib包的時候,它如果使用了自動升級,你是完全沒有辦法的。
所以一旦我們使用包依賴,自動升級的事情,是無法杜絕的。
慎用update
使用update操作的時候,必須想到會引發什么操作,盡量將composer.lock做下差異比對,明白下前后兩個依賴包差別在哪里。
總結
包依賴問題,不僅php有,golang也有,基本注意點都是如上,一樣的。
聲明:本網站發布的內容(圖片、視頻和文字)以原創、轉載和分享網絡內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。郵箱:3140448839@qq.com。本站原創內容未經允許不得轉載,或轉載時需注明出處:
三五互聯知識庫 »
一次因composer錯誤使用引發的問題與解決
主站蜘蛛池模板:
亚洲一本色道****AV|
亚洲欧洲∨国产一区二区三区|
国产中文字幕乱人伦在线观看|
久久超碰色中文字幕超清|
精品国产成人国产在线观看|
97成人精品一区二区三区狼人|
久久九九久精品国产|
欧美777|
国产一区二区精品久久凹凸|
亚洲第一综合天堂另类专|
国产精品视频超级碰|
人人妻人人爽人人澡av|
四虎在线成人免费观看|
免费观看日本污污ww网站69|
欧美久久久久中文字幕|
国产精品毛片久久久久久久|
日本高清在线播放一区二区三区|
亚洲国产成人精品女人久久久|
日日摸夜夜添夜夜添无码专区|
丝袜美腿一区二区三区|
国产视频 视频一区二区|
国产成人精品电影在线观看|
亚洲an第二区国产精品|
日日噜噜夜夜爽爽|
久久亚洲国产品一区二区|
老司机午夜免费精品视频|
国产亚洲人成A在线V网站|
亚洲色涩|
日韩中文字幕v亚洲中文字幕|
中日韩在线观看|
久久综合九色综合欧美98|
国产区成人精品视频|
国产毛片子一区二区三区|
图片区偷拍区小说区五月|
国产香蕉尹人在线观看视频|
色宅男看片午夜大片啪啪|
色屁屁www影院免费观看入口|
亚洲国产成人超福利久久精品|
国产99久久久国产精品~~牛|
色综合天天综合网天天看片|
熟女少妇内射日韩亚洲|