Piste :
Wiki: Plan du site - Derniers changements - Back link
Différences ¶
Ci-dessous, les différences entre deux révisions de la page.
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 11:42] – laurent | fr:tutoriels:utiliser-composer [2015/03/09 16:04] (Version actuelle) – [Développer une application et des modules séparément] laurent | ||
---|---|---|---|
Ligne 14: | Ligne 14: | ||
Une application développée avec Composer ne comporte normalement pas les bibliothèques tierces. C'est à dire que le code source de l' | Une application développée avec Composer ne comporte normalement pas les bibliothèques tierces. C'est à dire que le code source de l' | ||
- | 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' | + | 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' |
Pour créer un nouveau projet, deux choix. | Pour créer un nouveau projet, deux choix. | ||
Ligne 170: | Ligne 170: | ||
* Dans le composer JSON, vous indiquez non pas une version stable du paquet d'un module, mais sa branche de développement (" | * Dans le composer JSON, vous indiquez non pas une version stable du paquet d'un module, mais sa branche de développement (" | ||
- | * Vous pouvez alors faire des modifications dans les sources du module (dans vendor/), les tester avec votre application, | + | * Vous pouvez alors faire des modifications dans les sources du module (dans vendor/), les tester avec votre application, |
- | * **Attention** | + | |
- | | + | * **Attention** : ne manipulez pas Composer tant que vous n'avez rien commité et poussé sur les dépôts d' |
* 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 " | Une fois que votre module et votre application sont " | ||
- | |||
- | |||
- | |||
- | TODO: verifier le comportement de composer avec des changements dans le dépôt local de vendor/ | ||
- | |||
- | * changer de remote (sans modification) + composer update. | ||
- | * exemple: on est sur master -> origin/ | ||
- | * Résultat : RAS | ||
- | * changement dans la branche tracké via " | ||
- | * modif puis composer update/ | ||
- | * modif puis commiter puis composer update/ | ||
- | * modif puis commiter puis pusher puis composer update/ | ||
- | * changement dans la branche tracké via " | ||
- | * modif puis composer update/ | ||
- | * modif puis commiter puis composer update/ | ||
- | * modif puis commiter puis pusher puis composer update/ | ||
- | * modif puis composer update/ | ||
- | * modif puis commiter puis composer update/ | ||
- | * modif puis commiter puis pusher puis composer update/ | ||
- | * passage à une version stable dans le composer.json, | ||
- | * passage à une version stable dans le composer.json, | ||
- | * passage d'une version stable à instable. Résultat : ? | ||
- | * changement distant + composer update alors que l'on est sur origin master ou composer master. Résultat : mise à jour du remote composer mais pas du remote origin. Par contre mise à jour de la branche locale origin master mais pas la branche locale composer master. | ||
- | * changement distant + changement local + composer update alors qu'on est sur le remote composer. Résultat : ? | ||
- | * changement distant + changement local + composer update alors qu'on est sur le remote origin. Résultat : ? | ||