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的時(shí)候加入了7.1的特性
public function __construct(?string $locale, MessageFormatterInterface $formatter = null, string $cacheDir = null, bool $debug = false)
我機(jī)器上的版本是PHP 7.0。所以導(dǎo)致了在composer升級(jí)的時(shí)候symfony/http-kernel也升級(jí),帶來了symfony/translation升級(jí)到4.x,引入了PHP7.1的新特性。
解決方法
升級(jí)線上機(jī)器PHP版本是不可能的事情。于是我只能強(qiáng)制限定版本號(hào)。
直接在最上層我的項(xiàng)目中require symfony/translation,并且指定版本號(hào)。
"symfony/translation" : "3.3.13"
重新composer update 就可以了。
思考
這是一個(gè)典型的依賴包升級(jí)導(dǎo)致的業(yè)務(wù)應(yīng)用出錯(cuò)的案例。symfony/translation 從 3.3.13 升級(jí)到4.*,需要的PHP版本從7.0升級(jí)到7.1。這樣的升級(jí),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 是不是格外扎眼,根本已經(jīng)不靠譜了。
真正解決辦法
哈,其實(shí)這里并沒有結(jié)束。這個(gè)問題包版本依賴其實(shí)各個(gè)包都沒有問題。
其實(shí)這里有一個(gè)問題,我打包機(jī)器的PHP版本是7.1,但是線上機(jī)器是7.0.0,所以會(huì)導(dǎo)致這個(gè)問題。
其實(shí)composer比我們想象的更為強(qiáng)大。它會(huì)根據(jù)你當(dāng)前機(jī)器的PHP版本,判斷你的所有依賴分別使用什么版本,在composer update的時(shí)候,會(huì)根據(jù)所有依賴的版本需求選擇一個(gè)最好的版本。
所以我把我的打包機(jī)器上的PHP切換成7.0,查看生成的composer.lock,里面的symfony/translation就限制到使用3.3.x版本 就不會(huì)出現(xiàn)這個(gè)問題了。
composer的正確使用姿勢(shì)
是否要將composer.lock加入到git庫
這個(gè)是我這次犯的一個(gè)錯(cuò)誤,沒有將composer.lock進(jìn)入版本庫,打包機(jī)器composer install的時(shí)候就相當(dāng)于update操作了。對(duì)于業(yè)務(wù)來說,這個(gè)是不對(duì)的。業(yè)務(wù)要做的事情是保證業(yè)務(wù)穩(wěn)定性,其實(shí)任何的庫依賴的升級(jí),都需要經(jīng)過業(yè)務(wù)的測(cè)試和驗(yàn)證才能上線。所以,這里強(qiáng)烈建議在業(yè)務(wù)項(xiàng)目里面,將composer.lock強(qiáng)制加入git代碼庫中。
是否要使用自動(dòng)升級(jí)
版本依賴的時(shí)候,使用~,^符號(hào)會(huì)在composer udpate的時(shí)候根據(jù)依賴包已經(jīng)有的類庫。
我理解自動(dòng)升級(jí)的機(jī)制有好也有壞處,這個(gè)就相當(dāng)于把主動(dòng)權(quán)(這里已經(jīng)說的是update的主動(dòng)權(quán))放在哪里。作為一個(gè)基礎(chǔ)類庫,我當(dāng)然希望你使用我的時(shí)候能相信我,我的每次版本升級(jí)都是兼容的,也不會(huì)引入bug。所以類庫是會(huì)希望你會(huì)使用自動(dòng)升級(jí)。這樣我的一些bug修復(fù),在你update的時(shí)候你就會(huì)自動(dòng)下載并且修復(fù)了。
但是對(duì)于業(yè)務(wù)來說,業(yè)務(wù)穩(wěn)定是死要求。一旦我update的時(shí)候,我使用了你的新下載的包,這個(gè)實(shí)際上就有可能引入一個(gè)bug。沒有經(jīng)過完整的測(cè)試,是不應(yīng)該做這種操作的。
但是實(shí)際上,我們是無法完全杜絕這個(gè)情況,比如你的一個(gè)lib包依賴了另外一個(gè)lib包的時(shí)候,它如果使用了自動(dòng)升級(jí),你是完全沒有辦法的。
所以一旦我們使用包依賴,自動(dòng)升級(jí)的事情,是無法杜絕的。
慎用update
使用update操作的時(shí)候,必須想到會(huì)引發(fā)什么操作,盡量將composer.lock做下差異比對(duì),明白下前后兩個(gè)依賴包差別在哪里。
總結(jié)
包依賴問題,不僅php有,golang也有,基本注意點(diǎn)都是如上,一樣的。