Dependency patch resolution being removed from v2 of composer patches

[andybroomfield]

See https://www.cweagans.net/2023/07/dependency-patch-resolution/ and discussion https://github.com/cweagans/composer-patches/discussions/478

Have a feeling this will effect us as pathces as often added to modules. Will we have to document the effected patches and have them applied to the root composer.json fille?

Note that once composer-patches 2 is released, 1.x becomes unsupported?

Making the decision to drop this functionality was among the last major blockers for a 2.0.0 release. Another is making a decision on 1.x support. This will be detailed in the 2.0.0 release announcement, but the short version is that I’m going to do a couple of small, final updates to the 1.x branch prior to the 2.0.0 release, at which point 1.x will become effectively unsupported.

[stephen-cox]

This will mean changes to all root composer.json files, so is will require manually intervention to fix.

However, I also recognize that dependency patch resolution is a key part of many teams’ workflows. Composer Patches can be extended by other Composer plugins to provide this functionality again. Maybe some of the people who really need the functionality can band together and come up with a workable solution.

So it's possible that someone will come up with a solution.

Noting:

Arbitrary code execution is generally something we like to avoid, but Composer Patches allows a malicious package maintainer to do just that: somebody can apply a patch to any other package in your project, and the only indication that you’d have that something happened was a message in your Composer output.

So in an ideal world we need a mechanism to aggregate all composer patches only for LGD projects and apply these.

[finnlewis]

This thread is also interesting, recently linking to "an alternate library that does continue to support this use case: https://github.com/vaimo/composer-patches"

[finnlewis]

In the mean time, I'd like to clarify what works now for patching on an installed project, and what works for our testing regime, if it is different.