Geekly articles weekly

Compositeur PHP: corriger les dépendances sans douleur

Beaucoup d'entre vous ont probablement rencontré une situation où il y a un bogue ou non les fonctionnalités nécessaires dans la bibliothèque ou le framework que vous utilisez. Supposons que vous n'étiez pas trop paresseux et que vous ayez formé une demande de pull. Mais ils ne l'accepteront pas tout de suite, et la prochaine version du produit en général peut arriver dans un an.


Compositeur PHP: corriger les dépendances sans douleur


Que faire si vous devez de toute urgence appliquer la correction au produit? La solution évidente consiste à utiliser un fork d'une bibliothèque ou d'un framework. Cependant, tout n'est pas simple avec les fourches. L'utilisation de l'héritage pour remplacer la fonctionnalité qui doit être modifiée n'est pas toujours possible et nécessite souvent des changements majeurs. Les plugins pour Composer qui peuvent corriger les dépendances viennent à la rescousse.


Dans cet article, je parlerai davantage des raisons pour lesquelles les fourches ne sont pas pratiques, et je considérerai également deux plugins pour Composer pour les correctifs de dépendance: comment ils diffèrent, comment les utiliser et quels sont leurs avantages. Si vous avez rencontré des problèmes similaires ou si vous vous demandez simplement, bienvenue chez cat.


Le problème est plus facilement considéré avec un exemple. Disons que nous voulons changer quelque chose dans la bibliothèque de couverture de code PHP , qui est utilisée dans le framework de test PHPUnit pour mesurer le niveau de couverture de code par les tests. Supposons que nous voulons corriger quelque chose comme ça dans la version 7.0.8 (fichier 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(); }

Créons notre exemple de bibliothèque. Que ce soit php-composer-patches-example . Les détails ici ne sont pas très importants, mais si vous décidez de voir ce qu'est la bibliothèque, j'apporte la sortie de la console sous le spoiler.


Texte masqué
 $ 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

Quel est le problème avec une fourchette de dépendance


Voyons comment se produit la dépendance de fork. Essayons de bifurquer la couverture de code PHP.


  1. Nous allons à la page de couverture du code PHP sur GitHub .
  2. Appuyez sur le bouton Fork Bouton de fourche (note: vous aurez votre fourchette, remplacez mougrim par votre nom d'utilisateur).
  3. Clonez la fourche:
     cd ../ git clone git@github.com:mougrim/php-code-coverage.git cd php-code-coverage
  4. Accédez à la version que nous voulons corriger:
     git checkout 7.0.8
  5. Créez une branche pour le correctif:
     git checkout -b 7.0.8-myFix
  6. Nous apportons les modifications nécessaires, nous nous engageons, nous poussons:
     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. Ajoutez fork comme référentiel dans composer.json pour notre bibliothèque (cela est nécessaire pour que lors de la connexion du phpunit/php-code-coverage , pas le package d'origine soit connecté, mais le fork):
     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. Changez la version de la dépendance en brunch:
     composer.phar require phpunit/php-code-coverage 'dev-7.0.8-myFix'

Mais en fait, c'est encore plus compliqué: Composer dit que l'installation est impossible, car phpunit/phpunit nécessite la version de phpunit/php-code-coverage ^7.0.7 , et pour notre projet nécessite 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.

Que faire à ce sujet? Il y a quatre options:


  1. En plus du phpunit/php-code-coverage , forkez PHPUnit et écrivez la version dev-7.0.8-myFix pour la dépendance phpunit/php-code-coverage . Ce chemin est plutôt compliqué en termes de support et plus il est compliqué, plus les bibliothèques dépendent de la phpunit/php-code-coverage .
  2. Utilisez un alias lors de la connexion de phpunit/php-code-coverage . Mais les alias ne sont pas extraits des dépendances, ce qui signifie qu'ils devront toujours être écrits manuellement.
  3. Faites une phpunit/php-code-coverage dans votre fork afin que la balise 7.0.8 à un autre commit. Ce n'est au moins pas évident, mais au maximum - dans Git, il n'est pas pratique de travailler avec des balises qui font référence à différentes validations avec le même nom dans différents référentiels distants.
  4. Dans votre fork phpunit/php-code-coverage utilisez la balise alpha release, par exemple 7.0.8-a+myFix (il peut y avoir des collisions avec les versions alpha de la bibliothèque source).

Toutes les options ont leurs inconvénients. J'ai également essayé d'utiliser une balise comme 7.0.8.1 , mais Composer n'accepte pas de telles balises.


Les deuxième et quatrième options semblent le moindre des maux. Par le nombre d'actions, ils sont approximativement les mêmes, dans cet article, nous n'en considérerons qu'une - la quatrième. Créez une balise de version alpha:


 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

Supposons que nous voulons utiliser notre bibliothèque mougrim/php-composer-patches-example dans un projet qui dépend de phpunit/phpunit . Ici, on ne peut pas se passer du chamanisme, vous devrez à nouveau spécifier le référentiel https://github.com/mougrim/php-code-coverage.git pour phpunit/php-code-coverage , ainsi qu'indiquer explicitement la dépendance vis-à-vis de phpunit/php-code-coverage version 7.0.8-a+myFix (sinon l'installation 7.0.8-a+myFix ):


 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

Veuillez noter que php-composer-patches-example est connecté en tant que référentiel, car ce référentiel n'est qu'un exemple et n'a donc pas été ajouté à Packagist. Dans votre cas, cette étape sera probablement ignorée.


Pour résumer l'utilisation des fourches.


Les avantages de cette approche:


  • Pas besoin d'installer des plugins pour Composer.

Inconvénients de cette approche:


  • si vous utilisez roave/security-advisories , vous ne verrez pas d'informations indiquant que la version de la dépendance que vous avez créée et modifiée contient une vulnérabilité;
  • quand une nouvelle version de la dépendance sort, l'histoire de fork devra être répétée à nouveau;
  • si vous voulez corriger une dépendance de dépendance, comme dans l'exemple considéré, alors dev-* ne fonctionnera pas pour cela et vous devez chamaniser avec les versions ou fork pour les dépendances conflictuelles;
  • s'il existe des projets qui dépendent de votre bibliothèque, vous n'aurez pas à installer la bibliothèque dans le projet de la manière la plus évidente et la plus pratique;
  • s'il y a des projets qui dépendent de votre bibliothèque, pour eux la version phpunit/php-code-coverage sera strictement fixée, ce qui n'est pas toujours acceptable;
  • De plus, si les projets des points ci-dessus ont déjà bifurqué la couverture de code PHP pour une autre raison, alors tout devient encore plus compliqué.

Je pense que vous avez déjà réalisé que la dépendance à la fourche n'est pas une si bonne idée.


Utilisation de cweagans / composer-patches


Une fois de plus éprouvant de la douleur et de la souffrance en utilisant des fourches, je suis tombé sur des cweagans/composer-patches dans PHP Digest n ° 101 (au fait, pronskiy a un blog utile, je recommande de vous abonner). Il s'agit d'un plugin pour omposer, qui vous permet d'appliquer des correctifs aux dépendances. Après avoir lu la description, j'ai pensé que c'est exactement ce dont vous avez besoin.


Comment utiliser cweagans / composer-patches:


  1. Cloner la couverture du code PHP:
     cd ../ rm -rf php-code-coverage git clone git@github.com:sebastianbergmann/php-code-coverage.git cd php-code-coverage
  2. Accédez à la version que nous voulons corriger:
     git checkout 7.0.8
  3. Nous apportons les modifications nécessaires.
  4. Créez un 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. Dans notre projet, nous connectons des 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. Pour configurer cweagans/composer-patches ajoutez ce qui suit à composer.json (vous pouvez spécifier plusieurs correctifs pour un package):
     { "config": { "preferred-install": "source" }, "extra": { "patches": { "phpunit/php-code-coverage": { "My fix description": "patches/phpunit/php-code-coverage/myFix.patch" } }, "enable-patching": true } }
  7. Mettre à jour les dépendances:
     composer.phar update
  8. Si quelque chose s'est mal passé, cela peut être vu dans la sortie de la commande précédente, mais juste au cas où, vous pouvez vérifier que nos modifications ont été appliquées:
     $ grep example vendor/phpunit/php-code-coverage/src/CodeCoverage.php // for example some changes here
  9. Validez et poussez le résultat:
     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

Nous nous assurons que lors de l'installation de notre bibliothèque dans le projet, le patch s'appliquera également.


Créez un projet:


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

Ajoutez les lignes suivantes à composer.json :


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

Installez 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

Il semblerait que lors de la connexion du package, il aurait dû y avoir une tentative d'application du correctif, mais non.
Nous mettons à jour les packages pour que le patch s'applique, mais cela ne se produit pas:


 $ 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

Après avoir fouillé dans un outil de suivi des bogues, j'ai trouvé qu'un correctif basé sur un fichier n'était pas résolu dans le bogue des dépendances . Il s'avère que vous devez soit spécifier l'URL avant le correctif (ce qui signifie le télécharger quelque part), soit spécifier le chemin d'accès au correctif manuellement dans chaque projet où vous installez une dépendance qui nécessite des correctifs.


Pour résumer l'utilisation des cweagans/composer-patches .


Les avantages de cette approche:


  • le plugin a une communauté;
  • roave/security-advisories ne cessera pas de fonctionner;
  • lorsqu'une nouvelle version de la dépendance est publiée, si le correctif est appliqué avec succès, il suffira de s'assurer que tout fonctionne avec la nouvelle version (pour les versions mineures, avec une forte probabilité que cela fonctionne tout seul, pour les versions majeures, il est également probable que rien ne sera fait);
  • s'il y a des projets qui dépendent de votre bibliothèque, pour eux la version de phpunit/php-code-coverage ne sera pas strictement fixée;
  • De plus, dans le cas du paragraphe ci-dessus, un tel projet pourra appliquer ses correctifs en PHP Code Coverage.

Inconvénients:


  • Il s'agit d'un plugin pour Composer, ce qui signifie que lors de la mise à jour de Composer, il peut se casser;
  • enable-patching=true doit être spécifié pour que les correctifs soient appliqués à partir des dépendances;
  • le principal responsable du projet n'a pas beaucoup de temps pour le traiter, par conséquent, en règle générale, il accepte les demandes de tirage, mais ne développe pas particulièrement le projet (par exemple, il avait des idées pour la deuxième version de la tâche , mais peu de choses ont changé après trois ans);
  • il y a un correctif basé sur un fichier qui n'est pas résolu dans le bogue des dépendances , ce qui n'est pas pratique et est suspendu dans le backlog depuis trois ans maintenant;
  • Vous ne pouvez pas utiliser différents correctifs pour différentes versions de dépendances.

Le dernier point est devenu un obstacle pour moi. J'ai d'abord fait une demande de fonctionnalité . Le responsable a écrit qu'il ne voulait pas ajouter cette fonctionnalité au code principal, mais dans la deuxième version, il serait possible d'écrire un plug-in (oui, un plug-in pour le plug-in pour Composer). Les perspectives pour la deuxième version étaient vagues, j'ai donc décidé de chercher des alternatives. Parmi la petite liste, je n'ai pas trouvé de plugin qui serait pris en charge.


Je ne voulais pas entrer dans le code du plugin, j'ai donc décidé de bifurquer les fourches - c'est sûr, quelqu'un avait déjà rencontré le problème et l'avait résolu.


Utilisation des correctifs Vaimo Composer


Dans la plupart des fourches, il n'y avait aucune différence par rapport à l'original (pourquoi fourche-t-on même?). Une partie des fourches a été créée pour les demandes de tirage, qui ont déjà été fusionnées avec la bibliothèque principale. Cependant, il y avait un candidat intéressant qui résolvait mon problème - Vaimo Composer Patches . À cette époque, il était toujours défini comme une fourchette, mais son responsable, semble-t-il, n'allait pas faire de demandes de tirage. Entre autres choses, par exemple, il a déjà changé le nom du package en vaimo/composer-patches . Mais il y avait un problème: les problèmes étaient désactivés, c'est-à-dire qu'il n'y avait aucun retour de l'auteur. De plus, le plugin n'était pas hébergé sur Packagist .


Une telle bonne fourche ne doit pas être perdue dans un tas d'autres fourches inutiles. Par conséquent, j'ai contacté l'auteur pour lui demander d'activer les problèmes et d'ajouter un package à Packagist. Après presque un mois, l'auteur a répondu et a fait tout cela. :)


L'utilisation de vaimo/composer-patches pas différente de l'utilisation du plugin précédent, mais vous pouvez spécifier différents patchs pour différentes versions.


  1. Nous faisons reculer notre bibliothèque (la suppression du dossier vendor est nécessaire, car les plugins cweagans/composer-patches et vaimo/composer-patches ne vaimo/composer-patches pas très compatibles entre eux):
     cd ../php-composer-patches-example git checkout master rm -rf vendor/ composer.phar update
  2. Nous réalisons les points 1-4 de la section précédente.
  3. Dans notre projet, nous connectons des vaimo/composer-patches :
     cd ../php-composer-patches-example git checkout -b vaimoComposerPatches composer.phar require vaimo/composer-patches '^4.20.2'
  4. Pour configurer vaimo/composer-patches ajoutez ce qui suit à composer.json (la documentation peut être consultée ici ):
     { "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. Mettre à jour les dépendances:
     composer.phar update
  6. Si quelque chose s'est mal passé, cela peut être vu dans la sortie de la commande précédente, mais juste au cas où, vous pouvez vous assurer que nos modifications sont appliquées:
     $ grep example vendor/phpunit/php-code-coverage/src/CodeCoverage.php // for example some changes here
  7. Validez et poussez le résultat:
     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

Nous nous assurons que lors de l'installation de notre bibliothèque dans le projet, le patch s'appliquera également.


Créez un projet et installez 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

Au cas où, vous pouvez vous assurer que nos modifications ont été appliquées:


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

Pour résumer l'utilisation des vaimo/composer-patches .


Les avantages de ce plugin sont presque les mêmes que les précédents, mais incluent également les suivants:


  • le responsable développe activement le plugin et a déjà publié la quatrième version majeure;
  • il n'est pas nécessaire de prescrire quoi que ce soit de plus pour que les correctifs des dépendances soient appliqués;
  • Vous pouvez utiliser différents correctifs pour différentes versions de dépendances;
  • le plugin a beaucoup de paramètres, donc si la fonctionnalité décrite dans l'article ne vous suffit pas, alors regardez la documentation - peut-être que la fonctionnalité dont vous avez besoin est déjà implémentée.

Inconvénients:


  • comme le précédent, il s'agit d'un plugin pour Composer, ce qui signifie que lors de la mise à jour de Composer, il peut se casser;
  • contrairement au plugin précédent, cette communauté en a moins.

Conclusions


Pour résumer les résultats généraux:


  • l'utilisation de fourchettes de package pour des correctifs mineurs n'est pas pratique;
  • cweagans/composer-patches est un bon plugin, mais se développe mal, donc je ne le recommande pas;
  • Vaimo Composer Patches est un excellent plugin qui résout bien le problème de la correction des dépendances, et a également un tas de paramètres
  • Vaimo Composer Patches a une petite communauté, mais j'espère que cet article va l'augmenter;
  • si de nombreuses modifications sont nécessaires dans la dépendance, il peut être plus facile de recourir à un hard fork (garder le fork indépendant de la dépendance d'origine).

J'ai également fait une conclusion indirecte: si une sorte de dépendance ne fournit pas la fonctionnalité nécessaire, il peut y avoir des fourches qui ont implémenté cette fonctionnalité et encore plus.


Chez Badoo, nous utilisons les patchs Vaimo Composer dans deux cas:


  • dans SoftMocks pour patcher PHPUnit et PHP Code Coverage;
  • dans le référentiel interne du correctif Webmozart Assert pour la compatibilité avec SoftMocks en tant que correctif temporaire (alors que SoftMocks ne prend pas en charge les constructions array_map(array('static', 'valueToString') ).

Rinat Akhmadeev, Sr. Développeur PHP


UPD1 : Merci BoShurik pour le lien vers les alias . Ajout d'un point sur les alias à l'article.

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

More articles:


All Articles