一次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作下差别比对，明白下先后两个依赖包差异在哪里。

总结

包依赖问题，不只php有，golang也有，基本注意点都是如上，同样的。

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