Patches applied to a dependencies composer.json file produce unexpected results about composer-patches HOT 7 CLOSED

Sure. This question has come up a few times, so documenting it is probably a good idea. Thanks!

from composer-patches.

That is correct. This plugin changed what is saved on disk after downloading dependencies. You cannot change the dependency's package metadata, as that comes from Packagist. If you need different package metadata, you'll have to change the compose.json upstream or use a different package that incorporates those changes.

from composer-patches.

@arknoll Did that make sense ^ ? I'm not sure why you'd want to change a dependency's composer.json file, though. Can't you just make the changes in your root composer.json? That is, if a dependency requires version ~2.0 of vendor/package, and you need ~2.3, you can just require ~2.3 in your root package and composer will figure out that 2.3+ satisfies the requirement from the dependency too. Or maybe you're trying to do something else?

from composer-patches.

That does make sense, and I am trying to do something else. The upstream package has a bug in its composer.json file. Until a patch gets in upstream I am unable to use the package unless I fork it. (I can't just patch the composer file)

from composer-patches.

I see some limitations that are less than ideal:

• If you work around the problem by requiring your own copy of the sub-dependency in your root composer.json, you're limited by the precision declared in the dependent package's composer.json file. For example, if it specifies ~2.0, you're limited to 2.x, if it specifies ~2.0.0, you're limited to 2.0.x).
• If you work around the problem by specifying a forked upstream, you're stuck maintaining a fork until your patches/changes are merged in to the canonical.

Would it be unreasonable to incorporate some mechanism for pre/post-update application of patches?

from composer-patches.

There is no way around this. Composer calculates dependency versions and dependencies and such before the plugin is even instantiated. This plugin cannot be used to do what you want to do, and there is no plugin that will do what you want to do because what you want to do doesn't match with how composer works. You cannot patch a dependency's composer.json and expect it to work because composer install doesn't actually parse the dependency's composer.json.

You are stuck maintaining a fork until the canonical repo is fixed if you're wanting to change that dependency's composer.json.

from composer-patches.

Makes sense, thanks for the explanation. Would you be amenable to a PR w/documentation updates reflecting as much in the README.md?

from composer-patches.