Another kind of applying patch failing silenty

[mfrieling]

trafficstars

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?

I just had another case of a patch not being applied without any error message or information, aka silently. First I tried to apply the patch manually with git apply which failed as well, but patch -p1 , [patch-file] worked. After reading different issues why composer-patches uses git apply and not the patch command I decided to debug into composer prp if I can find the cause.

That was an easy one as it turned out being a typo in the package name inside composer.patches.json. So no bug at all, just a stupid (but time-consuming user error).

Describe your proposed solution(s)

As this might happen to other people as well, please add some useful output as warning or notice if a patch cannot be applied for different reasons, i. e.:

1. The package for which a patch is defined/locked cannot be found/is not installed.
2. The patch file is not downloadable/readable/...
3. Best possible error message returned from the patcher instance

No. 2 and 3 might already be implemented, I diidn't check the code for them. But no. 1 is the use case of this feature request.

If that might be too annoying consider putting these outputs behind a verbose flag.

Describe alternatives

No response

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!

[cweagans]

2 and 3 are already implemented, I think.

1 seems like a good idea as an opt-in behavior. I probably won't get to it in the near future -- should be pretty straightforward though. PRs welcome :)

1. After patches are resolved here: https://github.com/cweagans/composer-patches/blob/5d5261475adf2702f5a69a7f849c1124981f2825/src/Resolver.php#L59-L62
2. Get the list of installed packages: $this->composer->getLocker()->getLockedRepository()->getPackages()
3. Loop through the list of patches, get the package to which they apply, and see if that package is in the list of installed packages. If you come across one that isn't present and the config flag is set in the main plugin, throw an exception.

[mfrieling]

Thanks @cweagans. I would have done it here by changing the array_filter callback because when repatching is where the strange thing (patch silently not applied) happens: https://github.com/cweagans/composer-patches/blob/04107ec231481e1c078a158cc6a67ae3a6356940/src/Command/RepatchCommand.php#L38-L41

But it is probably better to do it when relocking as you suggested. At the moment I don't have time for it either.