Dois-je regarder manuellement mon module chaque fois que j'utilise un morceau de code Magento de base et que j'ajoute une ligne require: ... à composer.json?
Oui, chaque fois dans votre code que vous utilisez quelque chose d'un module principal, vous devez l'ajouter aux besoins de votre compositeur. Comme vous voulez probablement que votre ordre de chargement soit après le module principal, je suggère également de l'ajouter à votre module.xmlfichier dans la section séquence.
Ou existe-t-il un outil automatisé qui peut le faire pour moi?
Je n'en ai pas encore rencontré. Si c'est le cas, faites-le moi savoir. Il devrait être un outil assez sophistiqué et nécessiterait probablement une couverture de test substantielle, puis exécuterait une matrice de différentes versions pour produire un ensemble de travail.
Comment spécifier une version à inclure dans mon composer.json? Doit-il s'agir de la version de module spécifique contre laquelle j'ai développé? Ou devrais-je m'impliquer une sorte de caractère générique? Ou dois-je prendre une décision basée sur des compromis? Si oui, quels sont les compromis impliqués pour chaque style de version spécifiant?
Options pour définir un numéro de version
100.0.2
Ne fonctionne que lorsque cette version spécifique
100.0.*
*est un caractère générique et peut être remplacé par un numéro de la version
100.0.0, 100.0.1, ...,100.0.120
~100.0.2
Donne 2 un caractère générique qui ne peut monter si 100.0.2, 100.0.3, ...,100.0.120
^100.0.2
Permet toute libération jusqu'à 101 donc 100.0.2, 100.0.3, ..., 100.1.0,100.2.5
Pour les options 2 à 4, si vos paramètres de stabilité le permettent, cela inclurait également des versions comme 100.0.1-beta
Utilisation pratique
L'option 1.) est la plus prudente, vous savez contre quelle version vous avez développé et n'acceptez de travailler qu'avec cette version particulière - votre module ne peut être installé qu'avec ce module particulier dans cette version. Toutes les autres tentatives d'installation / mise à niveau échoueront avec un message de compositeur soulignant qu'il ne peut pas trouver un ensemble de composants installables.
Option 2.) Je pense que cela peut être considéré comme une option non couverte par l'option 3.) si vous l'utilisez comme ~100.0.0
Option 3.) Soyez compatible tant qu'aucune nouvelle fonctionnalité n'est introduite
Option 4.) Soyez compatible tant qu'aucun changement de rupture n'est introduit
Compromis
1 Votre extension ne fonctionne que pour 1 version d'un module Magento (techniquement s'il n'y a aucun changement dans un module, le numéro de version ne devrait pas augmenter et plusieurs versions du projet Magento pourraient théoriquement inclure le même module de base Magento avec la même version. Pratiquement, je n'ont pas vu cela et il semble que cela nécessite quelques modifications de processus à la fin de Magento, voir ici). Puisque vous êtes si étroitement lié à 1 version du module principal de Magento, vous vous retrouvez avec de nombreuses versions et versions de votre propre extension, si vous voulez rester compatible.
3-4 Votre extension fonctionne avec plusieurs versions de Magento et vous n'avez pas besoin de publier des versions différentes de votre extension à chaque fois que Magento publie une nouvelle version. L'inconvénient ici est que vous revendiquez la compatibilité même si un changement pourrait être introduit dans Magento qui est incompatible avec votre propre code. Ce risque est réel car la définition de Magento du versioning sémantique pour leurs propres versions de module ne s'étend qu'à ce qui est marqué d'une @apiannotation (plus à ce sujet dans ce numéro de GitHub ) avec sa portée limitée.
tl; dr;
100.0.2Jouez en toute sécurité, beaucoup de versions pour maintenir pour vous
^100.0.2le versioning sémantique comment cela devrait fonctionner, moins de versions pour vous, mais avec un risque plus élevé en raison de la portée limitée des @apiclasses et méthodes annotées. Si vous aviez une extension 100% utilisant des classes et des méthodes sanctionnées, ce serait le choix évident.