Question Est-ce que composer.lock doit être engagé dans le contrôle de version?


Je suis un peu confondu avec composer.lock utilisé dans une application avec un référentiel.

J'ai vu beaucoup de gens dire que nous ne devrions pas .gitignore  composer.lock à partir du référentiel.

Si je mets à jour mes bibliothèques dans mon environnement de développement, j'aurai une nouvelle composer.lock mais je ne serai pas en mesure de les mettre à jour dans la production, je vais?

Ne va-t-il pas générer des conflits sur ce fichier?


416
2017-10-15 13:36


origine


Réponses:


Si vous mettez à jour vos bibliothèques, vous voulez également valider le fichier de verrouillage. Il indique essentiellement que votre projet est verrouillé sur les versions spécifiques des bibliothèques que vous utilisez.

Si vous validez vos modifications et que quelqu'un extrait votre code et met à jour les dépendances, le fichier de verrouillage ne doit pas être modifié. Si elle est modifiée, cela signifie que vous avez une nouvelle version de quelque chose.

L'avoir dans le référentiel vous assure que chaque développeur utilise les mêmes versions.


542
2017-10-15 13:39



Pour les applications / projets: Définitivement oui.

le documentation du compositeur déclare à ce sujet (avec emphase):

Confirmez le compositeur.lock de votre application (avec composer.json) dans le contrôle de version.

Comme @meza a dit: Vous devriez commettre le fichier de verrouillage afin que vous et vos collaborateurs travailliez sur le même ensemble de versions et vous empêchiez de dire "Mais ça a marché sur mon ordinateur". ;-)

Pour les bibliothèques: Probablement pas.

Les notes de documentation du compositeur à ce sujet:

Remarque: pour les bibliothèques, il n'est pas forcément recommandé de valider le fichier de verrouillage (...)

Et déclare ici:

Pour votre bibliothèque, vous pouvez valider le fichier composer.lock si vous le souhaitez. Cela peut aider votre équipe à toujours tester les mêmes versions de dépendance. Cependant, ce fichier verrou n'aura aucun effet sur les autres projets qui en dépendent. Cela n'a d'effet que sur le projet principal.

Pour les bibliothèques, je suis d'accord avec la réponse de @Josh Johnson.


149
2018-06-16 15:41



Après avoir fait les deux façons pour quelques projets ma position est que composer.lock ne devrait pas être engagé dans le cadre du projet. Je sais que c'est plus facile à faire, mais s'il vous plaît supportez-moi pendant que je défends ma cause.

composer.lock est la construction de métadonnées qui ne fait pas partie du projet. L'état des dépendances doit être contrôlé par la façon dont vous les mettez à jour (manuellement ou dans le cadre de votre processus de génération automatisé) et non par le dernier développeur pour les mettre à jour et valider le fichier de verrouillage.

Si vous êtes préoccupé par le fait que vos dépendances changent entre les mises à jour du compositeur, vous avez un manque de confiance dans votre schéma de gestion des versions. Les versions (1.0, 1.1, 1.2, etc.) doivent être immuables et vous devez éviter les caractères génériques "dev-" et "X. *" en dehors du développement initial des fonctionnalités.

La validation du fichier de verrouillage est une régression pour votre système de gestion des dépendances car la version de dépendance est maintenant redevenue une définition implicite.

En outre, votre projet ne devrait jamais devoir être reconstruit ou ses dépendances requises dans chaque environnement, en particulier prod. Votre livrable (tar, zip, phar, un répertoire, etc.) doit être immuable et promu dans des environnements sans changement d'état.

Modifier: Je savais que ce ne serait pas une réponse populaire, mais si vous votez, seriez-vous assez aimable pour donner une raison dans les commentaires qui soulignent la faille dans la réponse? Merci!


61
2018-02-05 21:59



  1. Vous ne devriez pas mettre à jour vos dépendances directement sur Production.
  2. Vous devriez contrôler la version de votre composer.lock fichier.
  3. Vous ne devriez pas contrôler la version de vos dépendances réelles.

1. Vous ne devez pas mettre à jour vos dépendances directement sur Production, parce que vous ne savez pas comment cela affectera la stabilité de votre code. Il pourrait y avoir des bogues introduits avec les nouvelles dépendances, cela pourrait changer la façon dont le code agit sur le vôtre, il pourrait être incompatible avec d'autres dépendances, etc. Vous devriez le faire dans un environnement de développement, suivi par des tests de QA et de régression appropriés, etc. .

2. Vous devriez contrôler votre version composer.lock fichier, car cela stocke des informations sur vos dépendances et sur les dépendances de vos dépendances qui vous permettront de répliquer l'état actuel du code. Ceci est important, car tous vos tests et développements ont été réalisés avec un code spécifique. Ne pas se soucier de la version actuelle du code que vous avez est similaire à télécharger des modifications de code à votre application et ne pas les tester. Si vous mettez à niveau vos versions de dépendances, cela devrait être un acte volontaire, et vous devez prendre les précautions nécessaires pour vous assurer que tout fonctionne toujours. Perdre une ou deux heures de temps de retour à une version précédente peut vous coûter cher.

Un des arguments que vous verrez à propos de ne pas avoir besoin de la composer.lock est que vous pouvez définir la version exacte dont vous avez besoin dans votre composer.json fichier, et que de cette façon, chaque fois que quelqu'un court composer install, il va les installer le même code. Ce n'est pas vrai, car vos dépendances ont leurs propres dépendances, et leur configuration peut être spécifiée dans un format permettant de mettre à jour des sous-versions, voire des versions entières.

Cela signifie que même lorsque vous spécifiez que vous voulez Laravel 4.1.31 dans votre composer.json, Laravel dans son composer.json Le fichier peut avoir ses propres dépendances requises en tant que répartiteur d'événements Symfony: 2. *. Avec ce genre de configuration, vous pourriez vous retrouver avec Laravel 4.1.31 avec Symfony Event-Dispatcher 2.4.1, et quelqu'un d'autre dans votre équipe pourrait avoir Laravel 4.1.31 avec Event-Dispatcher 2.6.5, tout dépendra de quand était la dernière fois que vous avez exécuté l'installation du composeur.

Donc, avoir votre composer.lock fichier dans le système de version stockera la version exacte de ces sous-dépendances, donc, lorsque vous et votre coéquipier faites une installation par compositeur (c'est la manière dont vous installerez vos dépendances sur la base d'un composer.lock) vous aurez tous les deux les mêmes versions.

Et si vous voulez mettre à jour? Ensuite, dans votre environnement de développement, exécutez: composer update, cela va générer un nouveau composer.lock fichier (s'il y a quelque chose de nouveau) et après l'avoir testé, et le test d'assurance qualité et la régression le testent et d'autres choses. Vous pouvez le pousser pour que tout le monde télécharge le nouveau composer.lock, puisque c'est sûr de mettre à niveau.

3. Vous ne devriez pas contrôler la version de vos dépendances réellesparce que ça n'a aucun sens. Avec le composer.lock vous pouvez installer la version exacte des dépendances et vous n'auriez pas besoin de les valider. Pourquoi voudriez-vous ajouter à votre dépôt 10000 fichiers de dépendances, alors que vous n'êtes pas censé les mettre à jour. Si vous devez en changer un, vous devez le modifier et y apporter vos modifications. Et si vous craignez d’avoir à récupérer les dépendances réelles à chaque fois qu’une version ou une version est créée, le compositeur a différentes manières d’atténuer ce problème, le cache, les fichiers zip, etc.


24
2017-10-02 21:32



Vous commettez ensuite le composer.json à votre projet et tout le monde dans votre équipe peut exécuter l'installation du composeur pour installer les dépendances de votre projet.

Le but du fichier de verrouillage est d'enregistrer les versions exactes installées pour qu'elles puissent être réinstallées. Cela signifie que si vous avez une spécification de version de 1. * et que votre collègue exécute la mise à jour du composeur qui installe 1.2.4, puis valide le fichier composer.lock, lorsque vous composez l'installation, vous obtiendrez même 1.2.4 si 1.3.0 a été libéré. Cela garantit que tout le monde travaillant sur le projet a la même version exacte.

Cela signifie que si quelque chose a été commis depuis la dernière installation du compositeur, alors, sans fichier de verrouillage, vous obtiendrez un nouveau code tiers.

Encore une fois, c'est un problème si vous êtes préoccupé par votre code de rupture. Et c'est l'une des raisons pour lesquelles il est important de penser que Composer est centré sur le fichier composer.lock.

La source: Compositeur: tout est sur le fichier de verrouillage.


Confirmez le compositeur.lock de votre application (avec composer.json) dans le contrôle de version. Ceci est important car la commande install vérifie si un fichier de verrouillage est présent et, si tel est le cas, télécharge les versions spécifiées (indépendamment de ce que dit composer.json). Cela signifie que quiconque configure le projet télécharge exactement la même version des dépendances. Votre serveur CI, vos machines de production, les autres développeurs de votre équipe, tout et tout le monde s'exécutent sur les mêmes dépendances, ce qui réduit le risque de bogues affectant uniquement certaines parties des déploiements. Même si vous développez seul, en six mois, lors de la réinstallation du projet, vous pouvez être sûr que les dépendances installées fonctionnent toujours, même si vos dépendances ont publié de nombreuses nouvelles versions depuis.

La source: Compositeur - Utilisation de base.


4
2018-02-10 12:00



Si vous êtes préoccupé par votre code, vous devriez commettre le composer.lock à votre système de contrôle de version pour vous assurer que tous les collaborateurs de votre projet utilisent la même version du code. Sans fichier de verrouillage, vous obtiendrez un nouveau code tiers à chaque fois.

L'exception est lorsque vous utilisez une méta-application, des bibliothèques où les dépendances doivent être mises à jour lors de l'installation (comme le Zend Framework 2 Skeleton App). Donc, le but est de saisir les dernières dépendances chaque fois que vous voulez commencer à développer.

La source: Compositeur: tout est sur le fichier de verrouillage

Voir également: Quelles sont les différences entre la mise à jour du compositeur et l'installation du compositeur?


0
2018-06-26 12:43