|
| 1 | +Composer Plugin For Applying Patchsets |
| 2 | +====================================== |
| 3 | + |
| 4 | +This plugin can automatically apply patches to any dependency of your project. |
| 5 | + |
| 6 | +One of the most distinguishing features is that it can apply patches from special composer packages of type `patchset`. |
| 7 | +This is quite convenient as you can store all your patches in one repository and apply them automatically on all |
| 8 | +systems including developer's machines in a very predictable way. |
| 9 | + |
| 10 | +It's (kind-of) an alternative to two other great plugins (differences will become apparent once you read __Features__): |
| 11 | + |
| 12 | + * [netresearch/composer-patches-plugin](https://github.com/netresearch/composer-patches-plugin) |
| 13 | + * [cweagans/composer-patches](https://github.com/cweagans/composer-patches) |
| 14 | + |
| 15 | + |
| 16 | +## Features |
| 17 | + |
| 18 | + - Apply patches from dedicated composer packages (package your patchset!). |
| 19 | + - Each patch can have a version constraint (composer semver) checked against the target package. |
| 20 | + |
| 21 | + This means that you can (and should) have the patches fail the build if cannot be applied and still |
| 22 | + store patches for multiple package versions in the same patchset. |
| 23 | + - Apply patches using `patch` command and fall-back to `git apply` if not available. |
| 24 | + - Does not reinstall packages unnecessarily. |
| 25 | + - Reinstalls (cleans) packages which are patched but the patches have been removed guaranteeing a consistent |
| 26 | + state after multiple updates. |
| 27 | + - Will repatch packages even if **order** of patches for specific package (version) has changed. |
| 28 | + - Deduplicates patches on package level. |
| 29 | + - Does not overly tie into composer internals. All patching will be done after the main update/installation |
| 30 | + process at once execution making it simpler and easier to analyze. |
| 31 | + |
| 32 | + This also means that you have the guarantee that the plugin / patches are at the latest version before |
| 33 | + the process even starts. Otherwise it's very tricky (if not impossible) to make the plugin behave |
| 34 | + consistently on the first composer install (e.g. no `vendor` dir at all) and the subsequent ones. |
| 35 | + |
| 36 | + Double composer update/install for build is not necessary. |
| 37 | + |
| 38 | +### What it cannot do |
| 39 | + |
| 40 | + This plugin will not download patches from external sources directly (http). I consider this a bad practice and will |
| 41 | + never support it. I won't even comment on downloading patches using unencrypted connection without SHA check. Also what |
| 42 | + if somebody wants to use your software in 2 years and the patches are no longer available? |
| 43 | + |
| 44 | + Also you will not be able to specify patches in any composer package. You have to use a dedicated packages for this |
| 45 | + purpose. I can hardly imagine a legit use case when it would be desirable that installing package X will automatically |
| 46 | + patch some other package Y in your project without explicitly being advertised as a patchset. |
| 47 | + |
| 48 | +### What is missing |
| 49 | + |
| 50 | + - Patch the root package / files in root directory |
| 51 | + - Allow to specify patches in the root composer.json |
| 52 | + |
| 53 | + |
| 54 | + |
| 55 | +## Running tests |
| 56 | + |
| 57 | +Just start `vendor/bin/phpunit`. |
| 58 | +If you want to see the output of commands executed during functional testing use the `--debug` switch: |
| 59 | +``` |
| 60 | +vendor/bin/phpunit --debug |
| 61 | +``` |
| 62 | + |
| 63 | +It's nice to also add the `--testdox` switch then. |
| 64 | + |
0 commit comments