Shulou(Shulou.com)06/03 Report--

This article mainly introduces "how to solve the problems caused by the misuse of composer". In the daily operation, I believe many people have doubts about how to solve the problems caused by the misuse of composer. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "how to solve the problems caused by the misuse of composer". Next, please follow the editor to study!

Accident phenomenon

An online management backend, a management backend built using laravel, used to run well online before, but after today's comopser install, an error message appeared:

[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)

Accident analysis

This is a bottom-level library, basically, you can see at a glance that it is a version compatibility problem. When you go into the code, you can see that there is a line of code inside? string, which is a new feature introduced by php7.1.

I took a look at my composer.json, which mainly refers to the framework of laravel. The previous version of laravel/framework is "~ 5.5".

So I took it for granted that it was caused by the upgrade of the version of laravel, so I fixed the version of laravel to a subversion

"laravel/framework": "5.5.21"

It is found that this error will still occur. It is estimated that it may not be caused by the upgrade of the laravel version. So the version of laravel relies on the package "symfony/translation" that traces the problem.

The chain is as follows:

My project "laravel/framework": "5.5.21"

Laravel/framework "symfony/http-kernel": "~ 3.3"

Symfony/http-kernel (version 3.3.13) "symfony/translation": "~ 2.8 | ~ 3.0"

Symfony/http-kernel (version 3.4) "symfony/translation": "~ 2.8 | ~ 3.0 | ~ 4.0"

Symfony/translation3.4 version:

Public function _ _ construct ($locale, $formatter = null, $cacheDir = null, $debug = false)

In 4.0, the 7.1 feature was added.

Public function _ _ construct (? string $locale, MessageFormatterInterface $formatter = null, string $cacheDir = null, bool $debug = false)

The version on my machine is PHP 7. 0. This led to the upgrade of symfony/http-kernel when composer was upgraded, bringing the upgrade of symfony/translation to 4.x and the introduction of new features of PHP7.1.

Solution method

Upgrading the PHP version of an online machine is impossible. So I had to force a limited version number.

Require symfony/translation directly in my project at the top and specify the version number.

"symfony/translation": "3.3.13"

Re-composer update will be fine.

Thinking

This is a typical case of business application errors caused by dependency package upgrades. Symfony/translation is upgraded from 3.3.13 to 4.0, and the required PHP version is upgraded from 7.0 to 7.1. With such an upgrade, the laravel/framework version v5.5.21 is unaware.

And we look at (comopser.json) of laravel/framework v5.5.21 [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",},...}

Whether the PHP > = 7. 0 here is particularly eye-catching is not reliable at all.

The real solution

Ha, it's not over here. This problem package version depends on no problem with each package.

Actually, there is a problem here. The PHP version of my packing machine is 7.1, but the online machine is 7.0.0, so it will cause this problem.

Composer is actually more powerful than we thought. It will determine which version of all your dependencies to use according to the PHP version of your current machine, and will choose the best version according to the requirements of all dependent versions in composer update.

So I switched the PHP on my packaging machine to 7. 0, looked at the generated composer.lock, and the symfony/translation in it was limited to version 3.3.x and this problem would not occur.

Correct use posture of composer

Do you want to add composer.lock to the git library?

This is a mistake I made this time. Without putting composer.lock into the version library, packing machine composer install is equivalent to update operation. For business, this is not right. What the business needs to do is to ensure the stability of the business. in fact, any upgrade of the library dependency needs to be tested and verified by the business before it can be put online. Therefore, it is strongly recommended that composer.lock be forced into the git code base in the business project.

Do you want to use automatic upgrade

When the version is dependent, using the ~, ^ symbol will be based on the existing class libraries of the dependency package at the time of composer udpate.

I understand that the automatic upgrade mechanism has both advantages and disadvantages, which is equivalent to where to put the initiative (which is already talking about the initiative of update). As a basic class library, I certainly hope you can trust me when you use me. Every version upgrade is compatible and will not introduce bug. So the class library will want you to use automatic upgrades. In this way, some of my bug fixes will be downloaded and fixed automatically when you update.

But for business, business stability is a dead requirement. Once I update and I use your newly downloaded package, it's actually possible to introduce a bug. This should not be done without complete testing.

But in fact, we can not completely eliminate this situation, for example, when one of your lib packages depends on another lib package, if it uses an automatic upgrade, there is nothing you can do about it.

So once we use package dependencies, automatic upgrades cannot be stopped.

Use update cautiously

When using the update operation, you must think about what action will be triggered, and try to compare the differences between the composer.lock to understand the difference between the two dependency packages.

At this point, the study on "how to solve the problems caused by the misuse of composer" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.