Composer.lock doit-il être affecté au contrôle de version?
Je suis un peu confus avec composer.lock utilisé dans une application avec un référentiel.
J'ai vu beaucoup de gens dire qu'il ne faut pas .gitignorecomposer.lock à partir du référentiel.
Si je mets à jour mes bibliothèques dans mon environnement de développement, j'aurai un nouveau composer.lock mais je ne serai pas en mesure de les mettre à jour en production, vais-je?
Ne générera-t-il pas de conflits sur ce fichier?
Si vous mettez à jour vos bibliothèques, vous voulez aussi valider le fichier lockfile. Il indique en gros 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 lockfile ne doit pas être modifié. S'il est modifié, cela signifie que vous avez une nouvelle version de quelque chose.
Le fait de le placer dans le référentiel vous assure que chaque développeur utilise les mêmes versions.
Pour les applications/projets: définitivement oui.
La documentation du compositeur indique à ce sujet (avec emphase):
Commettez le composer composer.lock de votre application (avec composer.json) dans le contrôle de version.
Comme @Meza a déclaré: Vous devez valider le fichier de verrouillage pour que vos collaborateurs et vous travaillez sur le même ensemble de versions et vous empêchent de faire des énoncés tels que "Mais cela a fonctionné sur mon ordinateur". ;-)
Pour les bibliothèques: Probablement pas.
La documentation du compositeur note à ce sujet:
Note: Pour les bibliothèques, il n'est pas nécessairement 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 de verrouillage 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.
Après avoir utilisé les deux méthodes 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, tenez compte de moi pendant que je plaide en faveur de cela.
composer.lock est une métadonnée de construction qui ne fait pas partie du projet. L'état des dépendances doit être contrôlé en fonction de la façon dont vous les versez (manuellement ou dans le cadre de votre processus de génération automatisée) et non arbitrairement par le dernier développeur à les mettre à jour et à valider le fichier de verrouillage.
Si vous craignez que vos dépendances ne changent entre les mises à jour du compositeur, vous avez un manque de confiance en 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 d'entités initial.
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 redevenue implicite.
De plus, votre projet ne devrait jamais avoir à être reconstruit ou à avoir ses dépendances ré-acquises 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.
Edit: / Je savais que cela ne serait pas une réponse populaire, mais si vous votez, seriez-vous assez aimable pour fournir une raison dans les commentaires qui souligne le défaut de la réponse? Merci!
- Vous ne devriez pas mettre à jour vos dépendances directement sur Production.
- Vous devez contrôler la version de votre fichier composer.lock.
- Vous ne devriez pas contrôler les versions de vos dépendances réelles.
1. Vous ne devez pas mettre à jour vos dépendances directement sur Production , car vous ne savez pas comment cela affectera la stabilité de votre code. Il pourrait y avoir des bugs introduits avec les nouvelles dépendances, cela pourrait changer la manière dont le code affecte le vôtre, cela pourrait être incompatible avec d'autres dépendances, etc. Vous devriez le faire dans un environnement de développement, suivi d'un test de qualité et de régression approprié, etc. .
2. Vous devez contrôler la version de votre fichier composer.lock, car il 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 semblable au téléchargement de modifications de code dans votre application et de ne pas les tester. Si vous mettez à niveau vos versions de dépendances, cela doit ê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 fonctionnement pour revenir à une version antérieure peut vous coûter très cher.
Un des arguments que vous verrez sur le fait de ne pas avoir besoin de composer.lock est que vous pouvez définir la version exacte dont vous avez besoin dans votre fichier composer.json, et que de cette manière, chaque fois que exécute composer install, il installera 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 la mise à jour de sous-versions, voire de versions entières.
Cela signifie que même lorsque vous indiquez que vous souhaitez Laravel 4.1.31 dans votre composer.json, Laravel dans son fichier composer.json peut avoir ses propres dépendances requises en tant que répartiteur d'événements Symfony: 2. * . Avec ce type de configuration, vous pourriez vous retrouver avec Laravel 4.1.31 avec Symfony Event-Dispatcher 2.4.1, et un autre membre de votre équipe pourrait avoir Laravel 4.1.31 avec Event-Dispatcher 2.6.5. dépend de la dernière fois que vous avez exécuté l’installation du composeur.
Ainsi, avoir votre fichier composer.lock dans le système de version stockera la version exacte de ces sous-dépendances. Ainsi, lorsque vous et votre coéquipier installerez un composeur (c’est ainsi que vous installerez vos dépendances sur un composer.lock), vous obtiendrez les mêmes versions.
Et si vous voulez mettre à jour? Ensuite, dans votre environnement de développement, exécutez: composer update, cela générera un nouveau fichier composer.lock (s’il ya quelque chose de nouveau) et, après le test, un test d’assurance qualité et un test de régression. Vous pouvez le pousser pour que tout le monde télécharge le nouveau composer.lock, car il peut être mis à niveau en toute sécurité.
3. Vous ne devriez pas contrôler les versions de vos dépendances , car cela n’a aucun sens. Avec composer.lock, vous pouvez installer la version exacte des dépendances sans avoir à les valider. Pourquoi voudriez-vous ajouter à votre référentiel 10000 fichiers de dépendances, alors que vous n'êtes pas censé les mettre à jour? Si vous souhaitez modifier l'un de ces éléments, vous devez le créer et y apporter vos modifications. Et si vous craignez de devoir récupérer les dépendances réelles à chaque génération ou publication, compositeur dispose de différentes manières pour remédier à ce problème: cache, fichiers Zip, etc.
Vous validez ensuite le
composer.jsondans votre projet et tous les autres membres de votre équipe peuvent exécuter l'installation de composer pour installer les dépendances de votre projet.Le fichier de verrouillage a pour but d’enregistrer les versions exactes installées afin qu’elles puissent être réinstallées. Cela signifie que si vous avez une version spécifiée de 1. * et que votre collègue exécute la mise à jour de composer qui installe 1.2.4, puis valide le fichier composer.lock. Lorsque vous installez Composer, vous obtiendrez également 1.2.4, même si 1.3.0 a été publié. Cela garantit que tous ceux qui travaillent sur le projet ont la même version exacte.
Cela signifie que si quelque chose a été commis depuis la dernière installation d'un composeur, sans fichier verrou, vous obtiendrez un nouveau code tiers extrait.
Là encore, cela pose un problème si vous craignez que votre code ne soit cassé. C’est l’une des raisons pour lesquelles il est important de penser que Composer est centré sur le fichier composer.lock.
Source: Compositeur: Tout sur le fichier de verrouillage .
Commettez le composer composer.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, le cas échéant, télécharge les versions spécifiées à cet emplacement (quel que soit ce que composer.json dit). Cela signifie que toute personne qui configure le projet téléchargera 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 fonctionne sur les mêmes dépendances, ce qui limite le risque de bogues affectant seulement 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.
Source: Compositeur - Utilisation de base .
Il n'y a pas de réponse exacte à cela.
De manière générale, composer ne devrait pas faire ce que le système de construction est censé faire et vous ne devriez pas mettre composer.lock dans VCS. Compositeur pourrait étrangement avoir à l'envers. Les utilisateurs finaux plutôt que les produits ne devraient pas utiliser de fichiers de verrouillage. Habituellement, votre système de construction conserve des instantanés, des répertoires réutilisables, etc. plutôt qu'un répertoire vide à chaque fois. Les personnes empruntant une bibliothèque de composer pourraient vouloir que cette bibliothèque utilise un verrou afin que les dépendances utilisées par la bibliothèque aient été testées.
D'autre part, cela alourdit considérablement le fardeau de la gestion des versions, où vous voudriez presque certainement plusieurs versions de chaque bibliothèque, car les dépendances seront strictement verrouillées. Si chaque version de la bibliothèque est susceptible d’avoir une version légèrement différente, vous avez besoin de plusieurs versions de bibliothèque et vous pouvez également visualiser rapidement la taille des dépendances nécessaires, d'où le conseil de la garder sur la feuille.
En prenant cela en compte, je ne trouve vraiment pas que les fichiers de verrouillage soient utiles, ni pour les bibliothèques, ni pour vos propres répertoires de travail. Pour moi, c'est uniquement sur ma plate-forme de construction/tests que les ressources acquises en externe sont conservées. Elles ne sont mises à jour que sur demande, fournissant des versions répétables pour les tests, la construction et le déploiement. Bien que cela puisse être conservé dans VCS, il n'est pas toujours conservé dans l'arborescence source, mais les arborescences de construction se trouvent ailleurs dans la structure du VCS ou gérées par un autre système ailleurs. S'il est stocké dans un VCS, il est discutable de le conserver ou non dans le même référentiel que les arbres source, car sinon, chaque extraction peut générer une masse d'actifs de construction. J'aime assez avoir les choses dans un repo bien organisé, à l'exception des références de production/sensibles et des ballonnements.
SVN peut le faire mieux que git car il ne vous oblige pas à acquérir la totalité du repo (bien que je suppose que ce n’est pas vraiment nécessaire pour git non plus, mais le support pour cela est limité et n’est pas couramment utilisé). Les dépôts de construction simples sont généralement une simple branche superposée dans laquelle vous fusionnez/exportez l’arbre de construction. Certaines personnes combinent des ressources externes dans leur arbre source ou séparent des arbres externes, externes, de construction et source. Il sert généralement deux objectifs: construire des versions en mémoire cache et répétables, mais parfois le garder séparé à au moins un niveau permet également de créer facilement des versions vierges/vierges et plusieurs versions.
Il existe un certain nombre de stratégies pour cela et aucune d’entre elles ne fonctionne particulièrement bien pour maintenir la liste des sources à moins que vous ne conserviez une source externe dans votre arborescence.
Ils ont aussi des choses comme des hachages dans le fichier, comment cela fusionne-t-il lorsque deux personnes mettent à jour des paquets? Cela seul devrait vous faire penser que c'est peut-être mal interprété.
Les arguments avancés par les gens pour les fichiers de verrouillage sont des cas dans lesquels ils ont adopté un point de vue très spécifique et restrictif du problème. Vous voulez des constructions répétables et cohérentes? Incluez le dossier du fournisseur dans VCS. Ensuite, vous accélérez également l'extraction des ressources sans avoir à dépendre de ressources externes potentiellement défaillantes lors de la génération. Aucun des pipelines de génération et de déploiement que je crée ne nécessite un accès externe, à moins que cela ne soit absolument nécessaire. Si vous devez mettre à jour une ressource externe, c'est une et une seule fois. Ce que le compositeur essaie de réaliser est logique pour un système distribué, sauf comme il a été mentionné auparavant, car cela entraînerait un enfer dans la dépendance de bibliothèque pour les mises à jour de bibliothèque avec des conflits communs et des mises à jour aussi lentes que le paquet le plus lent à mettre à jour.
De plus, je mets à jour avec férocité. Chaque fois que je développe, je mets à jour et teste tout. Il existe une très très petite fenêtre dans laquelle une dérive de version significative peut se glisser. De manière réaliste également, lorsque la gestion sémantique est maintenue, ce qui est plutôt le cas pour le compositeur, vous n'êtes pas censé avoir autant de problèmes de compatibilité ou de problèmes.
Dans composer.json, vous mettez les paquetages dont vous avez besoin et leurs versions. Vous pouvez verrouiller les versions ici. Cependant, ces paquetages ont aussi des dépendances avec des versions dynamiques qui ne seront pas verrouillées par composer.json (bien que je ne vois pas pourquoi vous ne pourriez pas les mettre vous-même là si vous voulez qu'elles soient verrouillées par la version), de sorte que quelqu'un d'autre exécutant l'installation de composer obtient quelque chose de différent sans le verrou. Cela ne vous intéresse peut-être pas beaucoup, cela dépend. Devriez-vous vous en soucier? Probablement au moins un peu, suffisamment pour que vous soyez au courant de toute situation et de tout impact potentiel, mais cela ne devrait pas poser de problème non plus si vous avez toujours le temps de simplement DRY courir d'abord et réparer quoi que ce soit cela a été mis à jour.
Le compositeur embêtant essaie d'éviter parfois que ce ne soit pas le cas et que le fait d'avoir des fichiers de verrouillage du compositeur puisse entraîner des ennuis est considérable. Ils n'ont absolument aucun droit de dire aux utilisateurs ce qu'ils devraient ou ne devraient pas faire en ce qui concerne les actifs de compilation par rapport aux actifs source (que ce soit pour rejoindre une entité distincte dans VCS), car ce n'est pas leur affaire, ils ne sont ni votre patron, ni moi. "Le compositeur dit" n'est pas une autorité, ce n'est pas votre officier supérieur ni une supériorité sur qui que ce soit. Seulement vous savez votre situation réelle et ce qui est le mieux pour cela. Cependant, ils pourraient conseiller une ligne de conduite par défaut aux utilisateurs qui ne comprennent pas comment les choses fonctionnent. Dans ce cas, vous voudrez peut-être suivre cette procédure, mais personnellement, je ne pense pas que cela puisse réellement remplacer le fait de savoir comment les choses fonctionnent et de pouvoir les utiliser correctement. entraînement vos exigences. En fin de compte, leur réponse à cette question est une meilleure estimation. Les personnes qui fabriquent le compositeur ne savent pas où vous devriez garder votre compositeur. Leur seule responsabilité est de vous dire ce que c'est et ce qu'il fait. En dehors de cela, vous devez décider de ce qui vous convient le mieux.
Garder le fichier de verrouillage est problématique pour la facilité d'utilisation car composer est très secret sur l'utilisation ou non de lock ou de JSON et ne permet pas toujours d'utiliser les deux à la fois. Si vous exécutez install, il utilise uniquement le fichier de verrouillage qui apparaît. Par conséquent, si vous ajoutez quelque chose à composer.json, il ne sera pas installé car il ne se trouve pas dans votre verrou. Ce n’est pas du tout intuitif ce que font réellement les opérations et ce qu’elles font en ce qui concerne le fichier json/lock et parfois ne semblent même pas logiques (l’aide indique que l’installation prend un nom de package, mais qu’en essayant de l’utiliser, il dit non ).
Pour mettre à jour le verrou ou appliquer fondamentalement les modifications depuis le JSON, vous devez utiliser update et vous ne souhaitez peut-être pas tout mettre à jour. Le verrou a priorité pour choisir ce qui doit être installé. S'il y a un fichier de verrouillage, c'est ce qui est utilisé. Vous pouvez restreindre quelque peu la mise à jour, mais le système n’est encore qu’un gâchis.
Mise à jour prend un âge, des gigs de RAM. Je suppose également que si vous décrivez un projet qui n’a pas été touché pendant un certain temps, cela ressemblait aux versions qu’il a, il y en aura de plus en plus avec le temps et ce n’est probablement pas efficace, ce qui l’étrangle.
Ils sont très très sournois quand il s'agit d'avoir des commandes composites secrètes que vous ne pouviez pas vous attendre à être composites. Par défaut, la commande composer remove apparaît pour mapper à composeur update et composer remove par exemple.
La question que vous devez vraiment vous poser n’est pas de savoir si vous devez conserver le verrou dans votre arbre source ou si vous devez le conserver quelque part de quelque manière que ce soit, mais plutôt de demander ce qu’il fait réellement, alors vous pouvez décider vous-même. quand vous avez besoin de persister et où.
Je soulignerai que la possibilité de verrouiller est très pratique lorsque vous avez une stratégie de persistance de dépendance externe robuste car elle garde en mémoire les informations utiles pour le suivi de (les origines) et la mise à jour, mais si vous ne le faites pas. alors ce n'est ni ici ni là. Ce n'est pas utile quand il est forcé dans la gorge comme une option obligatoire de le polluer vos arbres sources. Il est très courant de trouver dans les bases de code héritées où des personnes ont apporté de nombreux changements à composer.json qui n'ont pas été réellement appliqués et qui sont brisés lorsque les utilisateurs essaient d'utiliser composeur. Pas de composer.lock, pas de problème de désynchronisation.
Si votre code vous préoccupe, vous devez valider le composer.lock dans 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 verrouillé, vous obtiendrez chaque fois un nouveau code tiers.
La seule exception est lorsque vous utilisez des méta-applications, des bibliothèques dans lesquelles les dépendances doivent être mises à jour lors de l'installation (comme/ Zend Framework 2 Skeleton App ). L'objectif est donc de récupérer les dernières dépendances à chaque fois que vous souhaitez commencer à développer.
Source: Compositeur: Tout est dans le fichier de verrouillage
Voir aussi: Quelles sont les différences entre la mise à jour du compositeur et son installation?