Remove dependency patch resolution

[cweagans]

This is something that I've wanted to do for a while, but we haven't had the infrastructure to let people add it on to the plugin if they really need this functionality. I was hesitant to add it in the first place, because allowing some arbitrary package to patch another has some security risks associated with it (imagine some contrib module just nuking the entire filter module in drupal/core).

Since PatchResolvers are now Composer Capabilities, this plugin can be extended by another plugin. I'm happy to help someone build out their own plugin to provide this functionality if there's strong enough interest. There is also some movement toward making patch application a Capability, so a third party plugin will be able to handle transforming the path to the patch file appropriately (to address issues like #39).

From a maintenance burden standpoint, this functionality has probably been one of the more difficult parts of the plugin. Aside from the security risks, it's been pretty error prone, and there are a ton of instances where multiple modules require the same patch (which causes problems - can't apply the same patch twice, the internal data structure doesn't really tolerate duplicate patches that well, etc).

[ElijahLynn]

Is this valid?

[cweagans]

Yeah, it's generated code from codeception.

[ElijahLynn]

👍

[AndreasA]

@cweagans Any news when this will be released with an official version because I think it is rather important 😄

[xurizaemon]

@AndreasA I had to look twice to realise that this PR removes support for resolving the path to patches in dependencies. From what I believe I see in current composer:

• Patches mentioned in dependences will be applied (if enable-patching is set true), if you reference patches by network URLs (relative paths don't apply)
• Patches mentioned in dependencies won't have their paths resolved, so they will be looked for relative to the project root not the dependency root.
• An external patch file reference also will be looked for relative to the project root, not the dependency root.

The change in this PR (merged April 2019) would have been released in 1.6.6 (May 2019) actually not clear about that, #322 (comment) says that resolving relative patches was still in as of April 2020. And now I wonder if I've read your comment backwards ...

[AndreasA]

@xurizaemon from what I can see the commit was merged forever ago but not yet included in a released version of the package which is weird. Personally, I think it makes more sense to specify all patches in the root only, to avoid weird side-effects and confusion.

[AndreasA]

@xurizaemon I have now checked the code for v1.x and according to this code line https://github.com/cweagans/composer-patches/blob/1.7.2/src/Patches.php#L436
the dependency patching is always enabled as soon as the root composer.json uses patches.
At least prior to this change which is part of 2.x and still not released.

[cweagans]

This pr only affects the 2.x release, which has no specific release date nor timeline. This will not be added to 1.x.