如何解決composer錯誤使用引發的問題

這篇文章主要介紹“如何解決composer錯誤使用引發的問題”，在日常操作中，相信很多人在如何解決composer錯誤使用引發的問題問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何解決composer錯誤使用引發的問題”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

事故現象

一個線上的管理后臺，一個使用laravel搭建的管理后臺，之前在線上跑的好好的，今天comopser install之后，出現錯誤信息：

[2019-02-25 16:00:33] production.ERROR: Parse error: syntax error, unexpected '?', expecting variable (T_VARIABLE) {"exception":"[object] (Symfony\\Component\\Debug\\Exception\\FatalThrowableError(code: 0): Parse error: syntax error, unexpected '?', expecting variable (T_VARIABLE) at /xxxx/application/estimate-admin/vendor/symfony/translation/Translator.php:89)

事故分析

這個是個底層庫，基本上，一看就知道是版本兼容問題，進去代碼一看，里面有行代碼是 ?string，這個是php7.1引入的一種新特性。

看了下我的composer.json，里面主要引用的是laravel的框架，之前的laravel/framework的版本是"~5.5"

于是想當然以為是laravel的版本升級導致的，于是我把laravel的版本固定到一個子版本

"laravel/framework": "5.5.21",

發現還是會出現這個錯誤。估摸可能不是laravel版本升級導致的。于是從laravel的版本依賴追到問題的包"symfony/translation"。

鏈條如下：

我的項目 "laravel/framework": "5.5.21",
  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做下差異比對，明白下前后兩個依賴包差別在哪里。

到此，關于“如何解決composer錯誤使用引發的問題”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！