Add a PatchPatcher plugin

[normanlolx]

Verification

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

Is your feature request related to a problem?

This is the default command that composer-patches v1 used to apply a patch:

patch '-p2' --no-backup-if-mismatch -d '/var/www/html/web/core' < '/mnt/ddev-global-cache/composer/patches/foobar.patch'

This is the default command that composer-patches v2 is using:

'git' -C '/var/www/html/web/core' apply --check --verbose -p2 '/mnt/ddev-global-cache/composer/patches/foobar.patch'

Problem with applying patches with git is: It doesn't have the built-in fuzzyness that patch has. For git the target file needs to look exactly as it's written in the .patch.

Now a lot of patches simply don't apply anymore with this message:

No available patcher was able to apply patch foobar.patch to drupal/core

Describe your proposed solution(s)

Similar to the existing GitPatcher plugin, add a PatchPatcher plugin.

This of course would contradict having it removed in v2 in the first place.

Which might make introducing another config option necessary to have the PatchPatcher disabled by default. To enable the PatchPatcher then people would need to enable it explicitly.

For example:

    "extra": {
        "composer-patches": {
            "include-patch-patcher": true
        }
    }

Describe alternatives

To make all patches getting applied with patch I can use the Freeform Patcher, but that would require changing all patches to the extended format, making the maintenance burden much higher.

Also not sure how that would work with nested patches coming from dependency's composer.json I can not control.

Additional context

Sample composer.json that works with v1 but does not work with v2:

composer.json

[github-actions]

👋 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!

[normanlolx]

Added a sample composer.json that works with v1 but does not work with v2.

[cweagans]

Adding patch support again is a nonstarter for me. I can't support/maintain that due to all of the different patch variants out there. 2.x had multiple patch patchers that would detect that right one to use, but it's just not worth it. If you really must have this, you can build a plugin that provides these patchers. I'd be happy to link to that new plugin from the docs.

main has #675 in it. Can you see if that restores some of the fuzziness that you're missing?

[rhuijts]

Problem with applying patches with git is: It doesn't have the built-in fuzzyness that patch has. For git the target file needs to look exactly as it's written in the .patch.

I ran into this as well, because my patch file starts with something like this:

--- ./project/file.php	2026-02-18 09:55:11.866257079 +0000
+++ ./patched/file.php	2026-02-18 09:56:20.711750645 +0000

and the patch command can use that to patch ./project/file.php without the ./patched directory existing. But git apply will fail with a No such file or directory error on that second path. To fix this, I had to edit the patch file into something like this (ironically making both paths nonexistent):

--- a/project/file.php	2026-02-18 09:55:11.866257079 +0000
+++ b/project/file.php	2026-02-18 09:56:20.711750645 +0000

and then git apply was happy with it. I create these patches with diff -Naur, not git diff. Is there a trick to make diff create patches that git apply can handle?

[cweagans]

Why not just make your patch with git in the first place?

[rhuijts]

Why not just make your patch with git in the first place?

Until two seconds ago I did not know that git diff also has a --no-index option to compare any two files outside of repositories, so my use case for diff has now diminished to systems that do not have Git. Thanks, this helps!

To answer my own question, the trick is probably to always diff on two paths where only the first component differs, e.g.

diff -Naur project/file.php patched-project/file.php

because the first part will get eaten by the -p1 option anyway.