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

This article will explain in detail how to use the replace attribute to avoid Composer dependency conflicts. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

The Composer documentation provides two basic examples. I will try to explain:

Lists the packages that have been replaced by this package. In this way, you can fork a package and release it under a different name with your own version number, while packages that need the original package can continue to use your fork package because it replaces the original package.

Suppose your software uses original/library and other/package, which themselves need original/library.

Now you think original/library needs to integrate new features, but the maintainers don't agree with your proposal to implement it in their package. So you decided to derive the library under the name better/library and mark a new release.

Go back to the software. Of course, it should start using the better/library package, so use it instead, but other/package still needs original/library-code repetition! How do you get that package to use your better/library instead of original/library? Instead of fork it, you just need to modify composer.json (you're still compatible with original/library, so it should work)?

You need to add the replace keyword to composer.json:

"replace": {"original/library": "1.0.2"}

Now Composer knows that any package from "better/library" is as good as "original/library" when it comes to resolving "other/package" dependencies.

This is also useful for packages that contain child packages, for example, the main symfony/symfony package contains all Symfony components, which can also be used as separate packages. If you need the main package, it will automatically meet the requirements of one of the individual components because it will replace them.

The same rules, but from a slightly different point of view: for any other component that requires some functionality, it is a good idea to introduce the components of the framework. However, if you need a complete framework in your software and another library needs components of the framework, the replace declaration of the framework eliminates the need for Composer to install the single component twice because it is already included in the complete framework.

Note: placeholders in replacement versions are usually bad

In my initial answer, I suggested:

"replace": {"original/library": "1.*"}

The consequence of this is that Composer will now make your library version 1.0.0 as good as any version 1.x of the original library, even if they one day fix something or add some features and release version 1.2.34. This also means that if one day your "other/package" is updated and you need "original/library: ^ 1.1", the replacement in your library is still active and declares that it can replace any version of the original library, even if you don't update anything inside-it can't be done, but if you don't do anything, your old code will never implement the new features of the original library. But the replacement illustrates this point.

So, in essence: avoid using wildcard versions in replacement versions! If you use them, you will make statements about the future that you cannot understand or predict (unless you can control original/library, but even so be very careful). Be sure to use original/library that you know and can be completely reimplemented.

This is the end of this article on "how to use the replace attribute to avoid dependency conflicts in Composer". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

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.