Bonjour,

J’utilise Composer depuis quelque temps déjà. Je pensais maîtriser l’outil, mais je suis confronté à un cas d’utilisation qui me pose problème.

Ce cas d’utilisation est un peu délicat à exprimer de façon synthétique, aussi je vais prendre un exemple.

• J’utilise le framework Slim V3.
• J’ai développé des « packages Composer » pour des modules fonctionnels indépendants du framework Slim V3 : « dbeurive/backend » et « dbeurive/rbac ».

Je souhaite créer deux « packages Composer » destinés à « intégrer » les deux packages que j’ai cités précédemment dans le framework Slim : « dbeurive/slim_backend » et « dbeurive/slim_rbac ».

Note :

L’intégration des modules fonctionnels au framework consiste à écrire un petit enrobage destiné à faciliter l’injection des fonctionnalités dans le DIC.

Le problème qui se pose est le suivant :

• Le module « dbeurive/slim_backend » dépend du package « slim/slim ».
• Le module « dbeurive/slim_rbac » dépend du package « slim/slim ».
• Le projet WEB que je vais créer dépendra également du package « slim/slim ».

Je ne vais tout de même pas déclarer la dépendance « slim/slim » dans les packages « dbeurive/slim_backend » et « dbeurive/slim_rbac ».

C’est à dire :
Note :

Pour tester les packages, j’ai besoin du framework Slim.

En effet, si je fais cela, les sources du framework Slim vont être présentes en triple exemplaire.

Comment gérer ce cas de figure ?

Je peux éventuellement déclarer le namespace associé à Slim dans la section « autoload » :
Mais, en faisant cela, j’intègre une dépendance vers une librairie « externe » au projet... L’utilisateur du package devra éditer le fichier « composer.json »... Bref, ce n’est pas pratique. Cette solution n’est pas satisfaisante.

Il doit exister une façon propre de gérer ce cas de figure... Mais je ne vois pas.

Une idée ?

Merci,

Denis

Bonjour à tous,

J’ai réalisé que je ne créais pas les « artéfacts » correctement. J’incluais dans le fichier d’archive ZIP le contenu du répertoire vendor.

D’un point de vue fonctionnel, cette pratique ne pose visiblement pas de problèmes évidents — à première vue. Composer ne génère pas d’avertissements et « tout fonctionne correctement », donc on pense bien faire.

Cela dit :

• Cette pratique n’est pas cohérente avec la raison d’être de l’outil Composer, à savoir gérer des dépendances.
• Cette pratique entraine des duplications de code.
• Cette pratique peut causer des problèmes délicats à diagnostiquer à partir du moment où vous utilisez plusieurs versions d’un même package dans vos différents packages (ou projets).

En conclusion il ne faut pas inclure le répertoire vendor dans les artéfacts.