Feature/post install patching #2
Conversation
…o store the new information
… + remove some useless code
…ts for keys that already exist (by not replacing them and rather appending them and converting type to array)
…istry differs, but patches are actually he same
Feature/package patches
Added more hints on the usage
Added more notes about enabling patching
Added alternative approach for defining patches in case load order is…
…ackages are present
…lanpaiste/composer-patches into feature/post-install-patching
Feature/post install patching
…ded explanation about why postInstall is hooked up with pre-autoloader generation
…hen patch file has changed, but has same name and description in composer.json
|
This is a whole lot of cool stuff! I noticed the activity in the GH contribution graph, so thought I'd come take a look. Before you get too much further into this, you should be aware of the 2.x branch of the plugin. I feel very strongly that a lot of this would be much easier to implement in 2.x, and I'd love to help get it in if you're interested. |
|
hey :) sorry for not answering earlier, but have been rushing through the changes so that we could start grouping patches with packages. anyhow - now I'm kind of regretting that I did not start with 2.x :( any kind of help would be greatly appreciated of course :) I'd probably could look into it over the weekend as well :) |
|
I'm unfortunately going to be completely unavailable until ~10/23, but after that point, I'm more than happy to assist. In the mean time, if you want to take a look at 2.x and see where/how your changes could fit in, that would be awesome! Note that 2.x is not entirely functional as of yet. It's more or less a rewrite. It has 100% test coverage so far though :) |
Fixes this notice on PHP 8.1: ``` Deprecation Notice: explode(): Passing null to parameter vaimo#2 ($string) of type string is deprecated in vendor/vaimo/composer-patches/src/Patch/SourceLoaders/PatchesSearch.php:234 ```
Background
Currently the patches are applied right after package install which means that developer has no way to add patches via packages due to not being able to define reverse-dependencies to some packages to dictate installation order.
This means that we currently don't have a way to move away from project-level patch management to something more granular that would be easy to maintain in larger scale (so that we could push certain patches to every project).
This branch is addressing the issue by moving the "apply instantly" logic to the moment of "apply when every package is installed".
Package patches
Extra changes to allow packages to have proper paths that are relative to the package root.
Another thing changed is the logic on how the patches are stored as multiple modules might end up overwriting each-others patches just because they have same description. Flipped this around so that the thing that has to be unique is the vendor path which will guarantee that you never end up being unpleasantly surprised.
Installation