Use the replace attribute to avoid Composer dependency conflicts

                                                                                                                                                    

The following tutorial column will introduce you to the method of using the replace attribute to avoid dependency conflicts in Composer. I hope it will be helpful to friends in need! The Composer documentation provides two basic examples. I'll try to explain:

List the packages that were replaced by this package. This way, you can fork a package and publish it under a different name with your own version number, and packages that require the original package can continue to use your forked package because it replaces the original package.

Assume your software uses

original/library

and

other/package

, which themselves require original/library. Now you think original/library needs to integrate new features, but the maintainers don't agree with your suggestion to be implemented in their package. So you decide to fork the library under the name

better/library

and mark it as a new release. Back to the software. Of course, it should start using the better/library package, so use that instead, but

other/package

still requires original/library - code duplication! How do you make that package use your better/library instead of original/library? Instead of forking it and just modifying composer.json (you're still compatible with original/library so it should work)? You need to add the replace keyword in composer.json:

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

Now Composer knows that when resolving the dependency of "other/package", any changes from "better" /library" packages are as good as "original/library".

This is also useful for packages that contain sub-packages, e.g. the main symfony/symfony package contains all Symfony components, which are also available as separate packages. If you need the main package, it will automatically satisfy the requirements for one of the individual components since it will replace them.

Same rule, just a slightly different perspective: Bringing in the framework's components is a good way to go for any other component that needs some functionality. However, if you need a complete framework in your software, and another library requires a component of that framework, the framework's

replace

declaration saves Composer from having to install that single component twice because it's already included in in a complete frame.

Note: placeholders in replacement versions are generally bad

In my original answer, I suggested:

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

This The consequence is: Composer will now treat version 1.0.0 of your library as good as any version 1.x of the original library, even if one day they fix something or add some features and release version 1.2.34 . This also means that if one day your "other/package" gets updated and requires "original/library:^1.1",

the replacement in your

library is still active and declares that it can be replaced Any version

1*

,, even if you don't update anything internally - it won't be done, but if you don't do any work, your old code will never implement the new functionality of the original library, But the replacement content illustrates exactly that. So, essentially: avoid using wildcard versions in replacement versions! If you use them, you are making statements about the future that you cannot know or predict (unless you have control over original/library , but even then be very careful). Be sure to use

original/library

that you know and can completely reimplement. Original address: https://stackoverflow.com/questions/18882201/how-does-the-replace-property-work-with-composer

Translation address: https: //learnku.com/laravel/t/55200

The above is the detailed content of Use the replace attribute to avoid Composer dependency conflicts. For more information, please follow other related articles on the PHP Chinese website!