Reapply all patches automatically when composer.lock got updated

[normanlolx]

Verification

• [x] I have updated Composer to the most recent stable release (composer self-update)
• [x] I have updated Composer Patches to the most recent stable release (composer update cweagans/composer-patches)
• [x] I am using one of the supported PHP versions (8.0+)
• [x] I have searched existing issues and discussions for my idea.

Is your feature request related to a problem?

Coming from #583 I'm suggesting to have this logic added to v2:

If the composer.lock file hash got updated, automatically re-apply patches.

Problem with v2 for me is:

1. I add a patch to an existing dependency in composer.json
2. I run composer patches-relock and composer update --lock to have patches.lock.json and composer.lock updated
3. Push
4. My colleagues pull the changes and as part of their routine run composer install expecting to get latest deps plus patches automatically

But.. no patches get installed. So now they always have to run composer patches-repatch themselves, no matter if a patch got added or not, to not miss any possible patches.

If composer-patches v2 thrived to solve the problem of patches always being re-applied although nothing changed, we are basically back at v1 now of having to run composer patches-repatch manually always to not miss any new patch for an existing dependency.

Describe your proposed solution(s)

If all three got changed: composer.json, composer.lock and patches.lock.json we should take maybe at least the composer.lock checksum change as marker to automatically re-apply the patches

Describe alternatives

Add @composer patches-repatch to post-install-cmd or always manually run composer patches-repatch

Additional context

No response

[github-actions[bot]]

👋 Thanks for the idea! Please remember that this is an open source project - feature requests may or may not be implemented, and if they are, the timeline is unknown. If you need a guaranteed implementation or timeline, sponsorships are welcome!

[RichardDavies]

I agree, the workflow with v1 was so much simpler and automated. composer install could detect when a patch was added or removed and handle it automatically. Now it feels like we've taken a step backwards and have to run an additional composer patches-repatch after composer install in case a new patch was added during a code pull/merge. And whenever a patch gets removed, we now have to manually delete the related dependency, whereas composer used to automatically do that for us.

It would be nice if these additional commands could be integrated/scripted into composer install so that there's a single command to add/remove/update patched dependencies like with v1.

[agoradesign]

At first, I wasn't aware that the patches weren't automatically taken into account during ‘composer install’ as they were in 1.x. The new lock file actually creates greater confidence – one implicitly assumes that this happens automatically and with much greater certainty than before. Fortunately, I haven't migrated too many projects to 2.x yet. I just realised that a few websites were unpatched in the last few days, and the resulting problems were limited. While correcting them, I noticed how uncertain I feel myself now. I had to run composer patches-repatch, followed by composer install --no-dev, because patching always loads the dev dependencies, which is not ideal, and finally I was unsure whether this had messed up the patches again and checked the changed files several times.

In any case, I have to come up with something for my projects. Maybe I'll downgrade to 1.x again. I hope we can find a general solution here. I feel sorry for the project maintainer, who has obviously put a tremendous amount of time, love and brainpower into refactoring version 2.x, and the basic idea contains some great improvements, but unfortunately this version is not currently suitable for productive use imho