Compositeur sans intégration continue

Si vous êtes un développeur WordPress qui utilise Composer sans intégration continue, il vous reste probablement une étape cruciale pour déterminer comment gérer le répertoire des fournisseurs lors du déploiement de vos plugins.

C’est-à-dire:

• Nous savons que c’est une mauvaise idée de jeter l’intégralité du répertoire du fournisseur sous contrôle de source,
• Les autres développeurs familiarisés avec l’utilisation de Composer devraient être en mesure de se lancer et de fonctionner sans avoir besoin de beaucoup d’instructions,
• L’intégration continue n’est pas utilisée pour un certain nombre de raisons,
• Et il nous reste à fournir un livrable de qualité production qui utilise certaines dépendances mais pas d’autres.

Bien que les points ci-dessus puissent décrire notre situation, ils ne nous disent pas ce que nous pouvons en faire.

En d’autres termes, voici le cas d’utilisation : vous avez créé un plugin WordPress pour quelqu’un. Ce plugin utilise une variété de dépendances qui sont toutes maintenues par Composer.

Vous n’archivez pas le répertoire du fournisseur dans le référentiel, mais vous n’utilisez pas non plus l’intégration continue pour déployer le plug-in. Au lieu de cela, le client est, ou un tiers est.

Alors quoi alors?

Distribution avec Composer sans intégration continue

La version courte est celle-ci :

Exportez la branche principale (ou la branche de version ou tout ce que vous appelez) à partir de votre copie locale du plug-in, puis assurez-vous d’exécuter la commande Composer qui lui demande de créer le répertoire du fournisseur sans les dépendances au niveau du développement.

Ensuite, vous pouvez regrouper l’archive générée et la distribuer à votre client.

Mais comment?

Tout d’abord, je suppose que la copie locale de votre plug-in n’a pas de copie du répertoire du fournisseur, mais contient tout le dernier code extrait du référentiel distant.

Autrement dit, vous avez la dernière version stable du code prête à être publiée, mais vous n’êtes pas encore prêt à le faire car il n’a pas les dépendances nécessaires pour, par exemple, le chargement automatique et d’autres fonctionnalités similaires.

La première étape va être d’exporter le référentiel local dans une archive. Voici comment vous pouvez le faire en le déposant sur votre bureau :

$ git archive -o ~/Desktop/plugin-name.zip HEAD

Ensuite, demandez à Composer d’ installer les dépendances qui sont en dehors de la directive require-devcomposer.json dans votre fichier :

$ composer install --no-dev

Vous pouvez maintenant archiver le répertoire généré dans un plugin et distribuer ce fichier.

Est-ce idéal ?

Je ne dirais pas que c’est idéal mais c’est une solution à un cas d’utilisation qui existe certainement, donc je dirais que c’est quelque chose qui peut être fait pour résoudre un problème spécifique.

En fin de compte, si vous cherchez un moyen de distribuer un plugin WordPress qui utilise Composer sans intégration continue, c’est une façon de le faire.

Je reconnais, cependant, qu’il s’agit d’un cas d’utilisation spécifique et a donc une solution spécifique.