Geekly articles weekly

PHP Composer: Korrigieren Sie Abhängigkeiten ohne Schmerzen

Viele von Ihnen sind wahrscheinlich auf eine Situation gestoßen, in der ein Fehler vorliegt oder nicht die erforderliche Funktionalität in der Bibliothek oder dem Framework, das Sie verwenden. Angenommen, Sie waren nicht zu faul und haben eine Pull-Anfrage erstellt. Sie werden es jedoch nicht sofort akzeptieren, und die nächste Veröffentlichung des Produkts kann in einem Jahr erfolgen.


PHP-Komponist: Korrigieren Sie Schadenigkeiten ohne Schmerzen


Was tun, wenn Sie die Korrektur dringend auf das Produkt übertragen müssen? Die naheliegende Lösung besteht darin, einen Zweig einer Bibliothek oder eines Frameworks zu verwenden. Mit Gabeln ist jedoch nicht alles einfach. Die Verwendung der Vererbung zum Überschreiben der zu ändernden Funktionen ist nicht immer möglich und erfordert häufig größere Änderungen. Plugins für Composer, die Abhängigkeiten patchen können, helfen.


In diesem Artikel werde ich mehr darüber sprechen, warum Gabeln unpraktisch sind, und zwei Plugins für Composer für das Patchen von Abhängigkeiten in Betracht ziehen: wie sie sich unterscheiden, wie sie verwendet werden und welche Vorteile sie haben. Wenn Sie auf ähnliche Probleme gestoßen sind oder sich nur fragen, sind Sie bei cat willkommen.


Das Problem wird am bequemsten anhand eines Beispiels betrachtet. Angenommen, wir möchten etwas in der PHP- Codeabdeckungsbibliothek ändern, die im PHPUnit-Testframework verwendet wird, um den Grad der Codeabdeckung durch Tests zu messen. Angenommen, wir möchten so etwas in Version 7.0.8 ( myFix.patch Datei) myFix.patch :


 diff --git a/src/CodeCoverage.php b/src/CodeCoverage.php index 2c92ae2..514171e 100644 --- a/src/CodeCoverage.php +++ b/src/CodeCoverage.php @@ -190,6 +190,7 @@ public function filter(): Filter */ public function getData(bool $raw = false): array { + // for example some changes here if (!$raw && $this->addUncoveredFilesFromWhitelist) { $this->addUncoveredFilesFromWhitelist(); }

Lassen Sie uns unsere Beispielbibliothek erstellen. Sei es ein PHP-Composer-Patches-Beispiel . Die Details hier sind nicht sehr wichtig, aber falls Sie sich entscheiden, die Bibliothek zu sehen, bringe ich die Konsolenausgabe unter den Spoiler.


Versteckter Text
 $ git clone git@github.com:mougrim/php-composer-patches-example.git   «php-composer-patches-example»… remote: Enumerating objects: 3, done. remote: Counting objects: 100% (3/3), done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0  : 100% (3/3), . $ cd php-composer-patches-example/ $ $ composer.phar init --name=mougrim/php-composer-patches-example --description="It's an example for article with using forks and patches for changing dependencies" --author='Mougrim <rinat@mougrim.ru>' --type=library --require='phpunit/phpunit:^8.4.2' --license=MIT --homepage='https://github.com/mougrim/php-composer-patches-example' Welcome to the Composer config generator This command will guide you through creating your composer.json config. Package name (<vendor>/<name>) [mougrim/php-composer-patches-example]: Description [It's an example for article with using forks and patches for changing dependencies]: Author [Mougrim <rinat@mougrim.ru>, n to skip]: Minimum Stability []: Package Type (eg library, project, metapackage, composer-plugin) [library]: License [MIT]: Define your dependencies. Would you like to define your dev dependencies (require-dev) interactively [yes]? no { "name": "mougrim/php-composer-patches-example", "description": "It's an example for article with using forks and patches for changing dependencies", "type": "library", "homepage": "https://github.com/mougrim/php-composer-patches-example", "require": { "phpunit/phpunit": "^8.4.2" }, "license": "MIT", "authors": [ { "name": "Mougrim", "email": "rinat@mougrim.ru" } ] } Do you confirm generation [yes]? yes Would you like to install dependencies now [yes]? yes Loading composer repositories with package information Updating dependencies (including require-dev) Package operations: 29 installs, 0 updates, 0 removals - Installing sebastian/version (2.0.1): Loading from cache - Installing sebastian/type (1.1.3): Loading from cache - Installing sebastian/resource-operations (2.0.1): Loading from cache - Installing sebastian/recursion-context (3.0.0): Loading from cache - Installing sebastian/object-reflector (1.1.1): Loading from cache - Installing sebastian/object-enumerator (3.0.3): Loading from cache - Installing sebastian/global-state (3.0.0): Loading from cache - Installing sebastian/exporter (3.1.2): Loading from cache - Installing sebastian/environment (4.2.2): Loading from cache - Installing sebastian/diff (3.0.2): Loading from cache - Installing sebastian/comparator (3.0.2): Loading from cache - Installing phpunit/php-timer (2.1.2): Loading from cache - Installing phpunit/php-text-template (1.2.1): Loading from cache - Installing phpunit/php-file-iterator (2.0.2): Loading from cache - Installing theseer/tokenizer (1.1.3): Loading from cache - Installing sebastian/code-unit-reverse-lookup (1.0.1): Loading from cache - Installing phpunit/php-token-stream (3.1.1): Loading from cache - Installing phpunit/php-code-coverage (7.0.8): Loading from cache - Installing doctrine/instantiator (1.2.0): Loading from cache - Installing symfony/polyfill-ctype (v1.12.0): Loading from cache - Installing webmozart/assert (1.5.0): Loading from cache - Installing phpdocumentor/reflection-common (2.0.0): Loading from cache - Installing phpdocumentor/type-resolver (1.0.1): Loading from cache - Installing phpdocumentor/reflection-docblock (4.3.2): Loading from cache - Installing phpspec/prophecy (1.9.0): Loading from cache - Installing phar-io/version (2.0.1): Loading from cache - Installing phar-io/manifest (1.0.3): Loading from cache - Installing myclabs/deep-copy (1.9.3): Loading from cache - Installing phpunit/phpunit (8.4.2): Loading from cache sebastian/global-state suggests installing ext-uopz (*) phpunit/phpunit suggests installing phpunit/php-invoker (^2.0.0) phpunit/phpunit suggests installing ext-soap (*) Writing lock file Generating autoload files $ $ echo 'vendor/' > .gitignore $ echo 'composer.lock' >> .gitignore $ git add .gitignore composer.json $ $ git commit --gpg-sign --message='Init composer' [master ce800ae] Init composer 2 files changed, 18 insertions(+) create mode 100644 .gitignore create mode 100644 composer.json $ git push origin master  : 4, . Delta compression using up to 4 threads.  : 100% (3/3), .  : 100% (4/4), 1.21 KiB | 1.21 MiB/s, . Total 4 (delta 0), reused 0 (delta 0) To github.com:mougrim/php-composer-patches-example.git f31c342..ce800ae master -> master

Was ist los mit einer Suchtgabel?


Mal sehen, wie Gabelabhängigkeit auftritt. Versuchen wir, die PHP-Code-Abdeckung zu teilen.


  1. Wir gehen zur Seite PHP Code Coverage auf GitHub .
  2. Drücken Sie die Gabel-Taste Gabelknopf (Hinweis: Sie haben Ihre Gabel, ersetzen Sie Mougrim durch Ihren Benutzernamen).
  3. Klonen Sie die Gabel:
     cd ../ git clone git@github.com:mougrim/php-code-coverage.git cd php-code-coverage
  4. Gehen Sie zu der Version, die wir patchen möchten:
     git checkout 7.0.8
  5. Erstellen Sie einen Zweig für die Korrektur:
     git checkout -b 7.0.8-myFix
  6. Wir nehmen die notwendigen Änderungen vor, verpflichten uns, drängen:
     git apply ../myFix.patch git add src/CodeCoverage.php git commit --gpg-sign --message='My fix' git push -u origin 7.0.8-myFix
  7. Fügen Sie fork als Repository in composer.json für unsere Bibliothek hinzu (dies ist erforderlich, damit beim Verbinden des phpunit/php-code-coverage Pakets nicht das Originalpaket, sondern der Fork verbunden wird):
     cd ../php-composer-patches-example git checkout -b useFork composer.phar config repositories.phpunit/php-code-coverage vcs https://github.com/mougrim/php-code-coverage.git
  8. Ändern Sie die Version für die Abhängigkeit in Brunch:
     composer.phar require phpunit/php-code-coverage 'dev-7.0.8-myFix'

Aber eigentlich ist es noch komplizierter: Composer sagt, dass die Installation unmöglich ist, da für phpunit/phpunit die Version ^7.0.7 für phpunit/php-code-coverage ^7.0.7 ist und für unser Projekt dev-7.0.8-myFix :


 $ composer.phar require phpunit/php-code-coverage 'dev-7.0.8-myFix' ./composer.json has been updated Loading composer repositories with package information Updating dependencies (including require-dev) Your requirements could not be resolved to an installable set of packages. Problem 1 - phpunit/phpunit 8.4.2 requires phpunit/php-code-coverage ^7.0.7 -> satisfiable by phpunit/php-code-coverage[7.0.x-dev]. - phpunit/phpunit 8.4.2 requires phpunit/php-code-coverage ^7.0.7 -> satisfiable by phpunit/php-code-coverage[7.0.x-dev]. - phpunit/phpunit 8.4.2 requires phpunit/php-code-coverage ^7.0.7 -> satisfiable by phpunit/php-code-coverage[7.0.x-dev]. - Can only install one of: phpunit/php-code-coverage[7.0.x-dev, dev-7.0.8-myFix]. - Installation request for phpunit/php-code-coverage dev-7.0.8-myFix -> satisfiable by phpunit/php-code-coverage[dev-7.0.8-myFix]. - Installation request for phpunit/phpunit ^8.4.2 -> satisfiable by phpunit/phpunit[8.4.2]. Installation failed, reverting ./composer.json to its original content.

Was tun? Es gibt vier Möglichkeiten:


  1. phpunit/php-code-coverage zusätzlich zur Gabel phpunit/php-code-coverage PHPUnit und schreiben Sie die Version dev-7.0.8-myFix für die Abhängigkeit phpunit/php-code-coverage . Dieser Pfad ist in Bezug auf die Unterstützung ziemlich kompliziert und je komplizierter, desto mehr Bibliotheken hängen von der phpunit/php-code-coverage von phpunit/php-code-coverage .
  2. Verwenden Sie einen Alias, wenn Sie phpunit/php-code-coverage . Aliase werden jedoch nicht aus den Abhängigkeiten gezogen, was bedeutet, dass sie immer manuell geschrieben werden müssen.
  3. phpunit/php-code-coverage in Ihrer Gabel eine phpunit/php-code-coverage sodass das 7.0.8 Tag 7.0.8 anderes Commit 7.0.8 . Dies ist zumindest nicht offensichtlich, aber maximal - in Git ist es unpraktisch, mit Tags zu arbeiten, die auf verschiedene Commits mit demselben Namen in verschiedenen Remote-Repositorys verweisen.
  4. phpunit/php-code-coverage in Ihrer Fork- phpunit/php-code-coverage das Alpha-Release-Tag, z. B. 7.0.8-a+myFix (es kann zu Kollisionen mit Alpha-Releases der 7.0.8-a+myFix kommen).

Alle Optionen haben ihre Nachteile. Ich habe auch versucht, ein Tag wie 7.0.8.1 , aber Composer akzeptiert solche Tags nicht.


Die zweite und vierte Option scheinen das geringere Übel zu sein. Aufgrund der Anzahl der Aktionen, die ungefähr gleich sind, werden wir in diesem Artikel nur eine - die vierte - betrachten. Erstellen Sie ein Alpha-Release-Tag:


 cd ../php-code-coverage git tag 7.0.8-a+myFix git push origin 7.0.8-a+myFix cd ../php-composer-patches-example composer.phar require phpunit/php-code-coverage '7.0.8-a+myFix' git add composer.json git commit --gpg-sign --message='Use fork' git push -u origin useFork

mougrim/php-composer-patches-example , wir möchten unser Beispiel für die Bibliothek mougrim/php-composer-patches-example in einem Projekt verwenden, das von phpunit/phpunit . Hier kann man nicht ohne Schamanismus phpunit/php-code-coverage , man muss erneut das Repository https://github.com/mougrim/php-code-coverage.git für phpunit/php-code-coverage angeben sowie explizit die Abhängigkeit von phpunit/php-code-coverage Version 7.0.8-a+myFix (andernfalls wird die Installation nicht erfolgreich sein):


 cd ../ mkdir php-project cd php-project/ composer.phar require phpunit/phpunit '^8.4.2' composer.phar config repositories.mougrim/php-composer-patches-example vcs https://github.com/mougrim/php-composer-patches-example.git composer.phar config repositories.phpunit/php-code-coverage vcs https://github.com/mougrim/php-code-coverage.git composer.phar require phpunit/php-code-coverage 7.0.8-a+myFix composer.phar require mougrim/php-composer-patches-example dev-useFork

Bitte beachten Sie, dass PHP-Composer-Patches-Beispiel als Repository verbunden ist, da dieses Repository nur ein Beispiel ist und daher nicht zu Packagist hinzugefügt wurde. In Ihrem Fall wird dieser Schritt höchstwahrscheinlich übersprungen.


Um die Verwendung von Gabeln zusammenzufassen.


Die Vorteile dieses Ansatzes:


  • Es müssen keine Plugins für Composer installiert werden.

Nachteile dieses Ansatzes:


  • Wenn Sie roave/security-advisories , werden keine Informationen roave/security-advisories , dass die Version der Abhängigkeit, die Sie gegabelt und geändert haben, eine Sicherheitsanfälligkeit enthält.
  • Wenn eine neue Version der Abhängigkeit herauskommt, muss die Fork-Story erneut wiederholt werden.
  • Wenn Sie eine Abhängigkeitsabhängigkeit wie im betrachteten Beispiel beheben möchten, dev-* nicht und Sie müssen mit Versionen oder Fork für widersprüchliche Abhängigkeiten schamanisieren.
  • Wenn es Projekte gibt, die von Ihrer Bibliothek abhängen, müssen Sie die Bibliothek nicht auf die offensichtlichste und bequemste Weise im Projekt installieren.
  • Wenn es Projekte gibt, die von Ihrer Bibliothek abhängen, wird für sie die phpunit/php-code-coverage streng festgelegt, was nicht immer akzeptabel ist.
  • Wenn die Projekte aus den oben genannten Punkten die Abdeckung von PHP-Code bereits aus einem anderen Grund verzweigten, wird alles noch komplizierter.

Ich denke, Sie haben bereits erkannt, dass es keine so gute Idee ist, Sucht zu forken.


Verwenden von Cweagans / Composer-Patches


Ich hatte wieder einmal Schmerzen und litt unter der Verwendung von Gabeln. In PHP Digest Nr. 101 stieß ich auf cweagans/composer-patches ( Pronskiy hat übrigens einen nützlichen Blog, ich empfehle, ihn zu abonnieren). Dies ist ein Plugin für omposer, mit dem Sie Patches auf Abhängigkeiten anwenden können. Nachdem ich die Beschreibung gelesen hatte, dachte ich, dass dies genau das ist, was Sie brauchen.


Verwendung von Cweagans / Composer-Patches:


  1. Klonen Sie die PHP-Code-Abdeckung:
     cd ../ rm -rf php-code-coverage git clone git@github.com:sebastianbergmann/php-code-coverage.git cd php-code-coverage
  2. Gehen Sie zu der Version, die wir patchen möchten:
     git checkout 7.0.8
  3. Wir nehmen die notwendigen Änderungen vor.
  4. Erstellen Sie einen Patch:
     mkdir -p ../php-composer-patches-example/patches/phpunit/php-code-coverage git diff HEAD > ../php-composer-patches-example/patches/phpunit/php-code-coverage/myFix.patch
  5. In unserem Projekt verbinden wir cweagans/composer-patches :
     cd ../php-composer-patches-example git checkout master composer.phar update git checkout -b cweagansComposerPatches composer.phar require cweagans/composer-patches '^1.6.7'
  6. cweagans/composer-patches zur Konfiguration von cweagans/composer-patches Folgendes zu composer.json (Sie können mehrere Patches für ein Paket angeben):
     { "config": { "preferred-install": "source" }, "extra": { "patches": { "phpunit/php-code-coverage": { "My fix description": "patches/phpunit/php-code-coverage/myFix.patch" } }, "enable-patching": true } }
  7. Abhängigkeiten aktualisieren:
     composer.phar update
  8. Wenn etwas schief gelaufen ist, wird dies in der Ausgabe des vorherigen Befehls angezeigt. Für alle Fälle können Sie jedoch überprüfen, ob unsere Änderungen übernommen wurden:
     $ grep example vendor/phpunit/php-code-coverage/src/CodeCoverage.php // for example some changes here
  9. Übernehmen und pushen Sie das Ergebnis:
     git add composer.json patches/phpunit/php-code-coverage/myFix.patch git commit --gpg-sign --message='Use cweagans/composer-patches' git push -u origin cweagansComposerPatches

Wir stellen sicher, dass bei der Installation unserer Bibliothek im Projekt auch der Patch angewendet wird.


Erstellen Sie ein Projekt:


 cd ../ rm -rf php-project mkdir php-project cd php-project composer.phar require phpunit/phpunit '^8.4.2'

Fügen Sie composer.json die folgenden Zeilen hinzu:


 { "extra": { "enable-patching": true } }

Installiere mougrim/php-composer-patches-example :


 composer.phar config repositories.mougrim/php-composer-patches-example vcs https://github.com/mougrim/php-composer-patches-example.git composer.phar require mougrim/php-composer-patches-example dev-cweagansComposerPatches

Es scheint, dass beim Anschließen des Pakets versucht werden sollte, den Patch anzuwenden, aber nein.
Wir aktualisieren die Pakete so, dass der Patch angewendet wird, aber dies passiert nicht:


 $ composer.phar update Removing package phpunit/php-code-coverage so that it can be re-installed and re-patched. - Removing phpunit/php-code-coverage (7.0.8) Loading composer repositories with package information Updating dependencies (including require-dev) Package operations: 1 install, 0 updates, 0 removals No patches supplied. Gathering patches for dependencies. This might take a minute. - Installing phpunit/php-code-coverage (7.0.8): Loading from cache - Applying patches for phpunit/php-code-coverage patches/phpunit/php-code-coverage/myFix.patch (My fix description) Could not apply patch! Skipping. The error was: The "patches/phpunit/php-code-coverage/myFix.patch" file could not be downloaded: failed to open stream: No such file or directory Writing lock file Generating autoload files

Nachdem ich in einem Bug-Tracker gestöbert hatte, stellte ich fest, dass ein dateibasierter Patch nicht im Abhängigkeitsfehler behoben wurde . Es stellt sich heraus, dass Sie entweder die URL vor dem Patch angeben müssen (dh von irgendwoher herunterladen) oder den Pfad zum Patch in jedem Projekt manuell angeben müssen, in dem Sie eine Abhängigkeit installieren, für die Patches erforderlich sind.


Um die Verwendung von cweagans/composer-patches .


Die Vorteile dieses Ansatzes:


  • Das Plugin hat eine Community.
  • roave/security-advisories werden nicht aufhören zu arbeiten;
  • Wenn eine neue Version der Abhängigkeit veröffentlicht wird und der Patch erfolgreich angewendet wird, reicht es aus, um sicherzustellen, dass alles mit der neuen Version funktioniert (bei kleineren Versionen funktioniert es mit hoher Wahrscheinlichkeit ganz von selbst, bei größeren Versionen ist es auch wahrscheinlich, dass nichts unternommen wird).
  • Wenn es Projekte gibt, die von Ihrer Bibliothek abhängen, wird für sie die Version von phpunit/php-code-coverage nicht streng festgelegt.
  • Darüber hinaus kann ein solches Projekt im Fall des obigen Absatzes seine Patches in PHP Code Coverage anwenden.

Nachteile:


  • Dies ist ein Plugin für Composer. Dies bedeutet, dass es beim Aktualisieren von Composer möglicherweise kaputt geht.
  • enable-patching=true muss angegeben werden, damit Patches aus Abhängigkeiten angewendet werden.
  • Der Hauptprojektbetreuer hat nicht viel Zeit, um sich damit zu befassen. Daher akzeptiert er in der Regel Pull-Anfragen, entwickelt das Projekt jedoch nicht besonders weiter (zum Beispiel hatte er Ideen für die zweite Version der Aufgabe , aber nach drei Jahren hat sich wenig geändert).
  • Es gibt einen dateibasierten Patch, der nicht im Abhängigkeitsfehler behoben wurde. Dies ist unpraktisch und hängt seit drei Jahren im Backlog.
  • Sie können keine unterschiedlichen Patches für unterschiedliche Versionen von Abhängigkeiten verwenden.

Der letzte Punkt ist für mich zu einer Barriere geworden. Zuerst habe ich eine Feature-Anfrage gestellt . Der Betreuer schrieb, dass er diese Funktion nicht zum Hauptcode hinzufügen wollte, aber in der zweiten Version wäre es möglich, ein Plug-In zu schreiben (ja, ein Plug-In für das Plug-In für Composer). Die Aussichten für die zweite Version waren vage, daher entschied ich mich, nach Alternativen zu suchen. In der kleinen Liste habe ich kein Plugin gefunden, das unterstützt werden würde.


Ich wollte nicht in den Plugin-Code einsteigen, also habe ich mich für Gabeln entschieden - sicher war jemand bereits auf das Problem gestoßen und hat es gelöst.


Verwenden von Vaimo Composer-Patches


Bei den meisten Gabeln gab es überhaupt keine Unterschiede zum Original (warum gabeln sie sich überhaupt?). Ein Teil der Gabeln wurde für Pull-Anfragen erstellt, die bereits mit der Hauptbibliothek zusammengeführt wurden. Es gab jedoch einen interessanten Kandidaten, der mein Problem löste - Vaimo Composer Patches . Zu dieser Zeit war es noch als Gabel gerahmt, aber sein Betreuer schien keine Pull-Anfragen zu stellen. So hat er beispielsweise bereits den Paketnamen in vaimo/composer-patches geändert. Aber es gab ein Problem: Probleme wurden deaktiviert, das heißt, es gab überhaupt kein Feedback vom Autor. Außerdem wurde das Plugin nicht auf Packagist gehostet.


Eine so gute Gabel sollte nicht in einem Stapel anderer nutzloser Gabeln verloren gehen. Daher habe ich den Autor mit der Bitte kontaktiert, Probleme zu aktivieren und Packagist ein Paket hinzuzufügen. Nach fast einem Monat antwortete der Autor und tat dies alles. :)


Die Verwendung von vaimo/composer-patches nicht von der Verwendung des vorherigen Plugins, Sie können jedoch verschiedene Patches für verschiedene Versionen angeben.


  1. Wir führen ein cweagans/composer-patches unserer Bibliothek durch (das Löschen des vendor Ordners ist erforderlich, da die Plugins cweagans/composer-patches und vaimo/composer-patches nicht sehr kompatibel sind):
     cd ../php-composer-patches-example git checkout master rm -rf vendor/ composer.phar update
  2. Wir führen die Punkte 1-4 aus dem vorherigen Abschnitt aus.
  3. In unserem Projekt verbinden wir vaimo/composer-patches :
     cd ../php-composer-patches-example git checkout -b vaimoComposerPatches composer.phar require vaimo/composer-patches '^4.20.2'
  4. vaimo/composer-patches zur Konfiguration von vaimo/composer-patches Folgendes zu composer.json (die Dokumentation finden Sie hier ):
     { "extra": { "patches": { "phpunit/php-code-coverage": { "My fix description": { "< 7.0.0": "patches/phpunit/php-code-coverage/myFix-leagcy.patch", ">= 7.0.0": "patches/phpunit/php-code-coverage/myFix.patch" } } } } }
  5. Abhängigkeiten aktualisieren:
     composer.phar update
  6. Wenn etwas schief gelaufen ist, wird dies in der Ausgabe des vorherigen Befehls angezeigt. Für alle Fälle können Sie jedoch sicherstellen, dass unsere Änderungen übernommen werden:
     $ grep example vendor/phpunit/php-code-coverage/src/CodeCoverage.php // for example some changes here
  7. Übernehmen und pushen Sie das Ergebnis:
     git add composer.json patches/phpunit/php-code-coverage/myFix.patch git commit --gpg-sign --message='Use vaimo/composer-patches' git push -u origin vaimoComposerPatches

Wir stellen sicher, dass bei der Installation unserer Bibliothek im Projekt auch der Patch angewendet wird.


Erstellen Sie ein Projekt und installieren Sie mougrim/php-composer-patches-example :


 cd ../ rm -rf php-project mkdir php-project cd php-project composer.phar require phpunit/phpunit '^8.4.2' composer.phar config repositories.mougrim/php-composer-patches-example vcs https://github.com/mougrim/php-composer-patches-example.git composer.phar require mougrim/php-composer-patches-example dev-vaimoComposerPatches

Für alle Fälle können Sie sicherstellen, dass unsere Änderungen übernommen wurden:


 $ grep example vendor/phpunit/php-code-coverage/src/CodeCoverage.php // for example some changes here

Um die Verwendung von vaimo/composer-patches .


Die Vorteile dieses Plugins sind fast dieselben wie bei den vorherigen, umfassen jedoch auch Folgendes:


  • Der Betreuer entwickelt das Plugin aktiv und hat bereits die vierte Hauptversion veröffentlicht.
  • Es ist nicht erforderlich, zusätzlich Patches aus Abhängigkeiten vorzuschreiben.
  • Sie können verschiedene Patches für verschiedene Versionen von Abhängigkeiten verwenden.
  • Das Plugin verfügt über viele Einstellungen. Wenn Ihnen die im Artikel beschriebene Funktionalität nicht ausreicht, lesen Sie die Dokumentation - möglicherweise ist die von Ihnen benötigte Funktion bereits implementiert.

Nachteile:


  • Wie das vorherige ist dies ein Plugin für Composer, was bedeutet, dass es beim Aktualisieren von Composer möglicherweise kaputt geht.
  • Im Gegensatz zum vorherigen Plugin hat diese Community weniger.

Schlussfolgerungen


Um die allgemeinen Ergebnisse zusammenzufassen:


  • Die Verwendung von Paketgabeln für kleinere Korrekturen ist unpraktisch.
  • cweagans/composer-patches ist ein gutes Plugin, entwickelt sich aber schlecht, daher empfehle ich es nicht
  • Vaimo Composer Patches ist ein hervorragendes Plugin, das das Problem der Behebung von Abhängigkeiten gut löst und außerdem eine Reihe von Einstellungen enthält.
  • Vaimo Composer Patches hat eine kleine Community, aber ich hoffe, dieser Artikel wird sie erweitern.
  • Wenn in der Abhängigkeit viele Änderungen erforderlich sind, ist es möglicherweise einfacher, auf eine harte Gabel zurückzugreifen (halten Sie die Gabel unabhängig von der ursprünglichen Abhängigkeit).

Ich habe auch eine indirekte Schlussfolgerung gezogen: Wenn eine Art von Abhängigkeit nicht die erforderliche Funktionalität bietet, gibt es möglicherweise Gabeln, die diese Funktionalität implementiert haben, und noch mehr.


Bei Badoo verwenden wir Vaimo Composer Patches in zwei Fällen:


  • in SoftMocks zum Patchen von PHPUnit und PHP Code Coverage;
  • im internen Repository für den Webmozart Assert-Fix zur Kompatibilität mit SoftMocks als temporären Fix (während SoftMocks keine array_map(array('static', 'valueToString') Konstruktionen unterstützen array_map(array('static', 'valueToString') ).

Rinat Akhmadeev, Sr. PHP-Entwickler


UPD1 : Danke BoShurik für den Link zu Aliasen . Dem Artikel wurde ein Punkt über Aliase hinzugefügt.

Source: https://habr.com/ru/post/de473654/

More articles:


All Articles