一次composer錯誤使用引起的思考

一次composer錯誤使用引起的思考

這個思考源自於一個事故。讓我對版本依賴從新思考了一下。php

事故現象

一個線上的管理後臺,一個使用laravel搭建的管理後臺,以前在線上跑的好好的,今天comopser install以後,出現錯誤信息:html

[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引入的一種新特性。laravel

看了下個人composer.json,裏面主要引用的是laravel的框架,以前的laravel/framework的版本是"~5.5"git

因而想固然覺得是laravel的版本升級致使的,因而我把laravel的版本固定到一個子版本github

"laravel/framework": "5.5.21",

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

鏈條以下:json

個人項目 "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版本:php7

public function __construct($locale, $formatter = null, $cacheDir = null, $debug = false)

而在4.0的時候加入了7.1的特性app

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的新特性。composer

解決方法

升級線上機器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也有,基本注意點都是如上,同樣的。

原文出處:https://www.cnblogs.com/yjf512/p/10475938.html

相關文章
相關標籤/搜索