| Les deux révisions précédentesRévision précédenteProchaine révision | Révision précédente |
| fr:tutoriels:utiliser-composer [2015/03/09 09:03] – [Développer une application et des modules séparément] laurent | fr:tutoriels:utiliser-composer [2015/03/09 16:04] (Version actuelle) – [Développer une application et des modules séparément] laurent |
|---|
| Une application développée avec Composer ne comporte normalement pas les bibliothèques tierces. C'est à dire que le code source de l'application, dans un dépôt git, subversion ou mercurial, ne contient pas le code source de ces bibliothèques tierces. Elles sont installées par Composer lors du déploiement de l'application (que ce soit en local pour développer ou sur un serveur de déploiement pour la mise en production). | Une application développée avec Composer ne comporte normalement pas les bibliothèques tierces. C'est à dire que le code source de l'application, dans un dépôt git, subversion ou mercurial, ne contient pas le code source de ces bibliothèques tierces. Elles sont installées par Composer lors du déploiement de l'application (que ce soit en local pour développer ou sur un serveur de déploiement pour la mise en production). |
| |
| Ainsi, une application utilisant le framework Jelix 1.7+ avec Composer, ne devrait pas inclure Jelix dans son code source, et indiquer plutôt le paquet Jelix dans le fichier composer.json de l'application. Composer installera alors les fichiers de Jelix (et autres bibliothèques) dans un dossier @@vendor/@@ (que vous ne devez donc pas inclure dans votre dépôt git/svn/hg). | Ainsi, une application utilisant le framework Jelix 1.7+ avec Composer, ne devrait pas inclure Jelix dans son code source, et indiquer plutôt le paquet Jelix dans le fichier composer.json de l'application. Composer installera alors les fichiers de Jelix (et autres bibliothèques) dans un dossier @@vendor/@@ (que [[https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md|vous ne devez donc pas inclure dans votre dépôt]] git/svn/hg). |
| |
| Pour créer un nouveau projet, deux choix. | Pour créer un nouveau projet, deux choix. |
| ===== Développer une application et des modules séparément ===== | ===== Développer une application et des modules séparément ===== |
| |
| Il arrive que l'on développe une application qui utilise des modules externes (utilisés par d'autres projets) que l'on a soit-même développé ou auxquels on contribue. Et que l'on veuille dans le même temps améliorer le code de ces modules externes. Cependant, les installer avec Composer impose que l'on commit les modifications dans leurs dépôts respectifs. Cela veut dire qu'il va certainement falloir commiter à de nombreuses reprises lors du debuggage et la mise au point. De quoi "pourrir" l'historique du dépôt des modules. Et de nombreux "Composer update" en ligne de commande... | Il arrive que l'on développe une application qui utilise des modules externes (utilisés par d'autres projets) que l'on a soit-même développé ou auxquels on contribue. Et que l'on veuille dans le même temps améliorer le code de ces modules externes. |
| | |
| | On aurait donc une application dans un dépôt git, et les autres modules dans d'autres dépôt git. L'application aurait son composer.json référençant les paquets de ces modules, et donc au final un répertoire @@vendor/@@ contenant les fichiers de ces modules. |
| | |
| | Cependant, installer ces modules avec Composer impose que l'on commit les modifications dans leurs dépôts respectifs. Cela veut dire qu'il va certainement falloir commiter à de nombreuses reprises lors du debuggage et la mise au point. De quoi "pourrir" l'historique du dépôt des modules. Et de nombreux "Composer update" en ligne de commande... |
| |
| On peut bien sûr limiter ces commits en écrivant des tests unitaires dans les dépôts des modules, mais cela n'est pas toujours suffisant : on ne peut pas tester l'intégration du module dans une application... sans application. | On peut bien sûr limiter ces commits en écrivant des tests unitaires dans les dépôts des modules, mais cela n'est pas toujours suffisant : on ne peut pas tester l'intégration du module dans une application... sans application. |
| |
| * Dans le composer JSON, vous indiquez non pas une version stable du paquet d'un module, mais sa branche de développement ("dev-quelquechose"). Vous avez alors, dans le répertoire du module dans @@F@vendor/@@, un clone Git du projet du module, et non pas uniquement ses sources (C'est une des raisons d'ailleurs pour laquelle il ne faut jamais inclure le répertoire vendor). | * Dans le composer JSON, vous indiquez non pas une version stable du paquet d'un module, mais sa branche de développement ("dev-quelquechose"). Vous avez alors, dans le répertoire du module dans @@F@vendor/@@, un clone Git du projet du module, et non pas uniquement ses sources (C'est une des raisons d'ailleurs pour laquelle il ne faut jamais inclure le répertoire vendor). |
| * Vous pouvez alors faire des modifications dans les sources du module (dans vendor/), les tester avec votre application, et commiter dans le dépôt du module comme à votre habitude, quand les modifications sont terminées. | * Vous pouvez alors faire des modifications dans les sources du module (dans vendor/), les tester avec votre application, et commiter dans le dépôt du module comme à votre habitude, quand les modifications sont terminées, en tenant compte des informations suivantes : |
| * **Attention** : ne manipulez pas Composer tant que vous n'avez rien commiter | * Dans le dépôt du module (dans vendor/), vous remarquerez que deux "remote" sont déclarés : "composer" et "origin". Il faut travailler sur une branche issue de "origin": le push sera facilité |
| * Dans le dépôt du module (dans vendor/), vous remarquerez que deux "remote" sont déclarés : "composer" et "origin". | * **Attention** : ne manipulez pas Composer tant que vous n'avez rien commité et poussé sur les dépôts d'origine, en particulier si d'autres personnes sont susceptibles de commiter dans le dépôt d'origine. Un "composer update" pourrait écraser vos modifications ou vos commits locaux. Si vous avez vraiment besoin de faire un "composer update" et qu'il est succeptible d'avoir des nouveaux commits distant, travaillez alors sur une nouvelle branche locale : Composer n'y touchera pas. |
| * Enfin, une fois que le module est stable, vous mettrez un tag de version (ex: v1.0) dans le dépôt du module. | * Enfin, une fois que le module est stable, vous mettrez un tag de version (ex: v1.0) dans le dépôt du module. |
| |
| Une fois que votre module et votre application sont "stables", vous changerez alors la version du module dans le composer.json de l'application, en indiquant le numéro de version stable du module. | Une fois que votre module et votre application sont "stables", vous changerez alors la version du module dans le composer.json de l'application, en indiquant le numéro de version stable du module. |
| |
| |
| |
| TODO: verifier le comportement de composer avec des changements dans le dépôt local de vendor/monmodule/: | |
| |
| * changement dans la branche tracké via "composer" | |
| * modif puis composer update/install : resultat ? | |
| * modif puis commiter puis composer update/install : resultat ? | |
| * modif puis commiter puis pusher puis composer update/install : resultat ? | |
| * changement dans la branche tracké via "origin" | |
| * modif puis composer update/install : resultat ? | |
| * modif puis commiter puis composer update/install : resultat ? | |
| * modif puis commiter puis pusher puis composer update/install : resultat ? | |
| |
| |
| |
