Faut-il que composer.lock soit engagé dans le contrôle de version?

Je suis un peu confus avec composer.lockutilisé dans une application avec un référentiel.

J'ai vu beaucoup de gens dire que nous ne devrions pas .gitignore composer.lockquitter le référentiel.

Si je mets à jour mes bibliothèques dans mon environnement de développement, j'en aurai une nouvelle composer.lockmais je ne pourrai pas les mettre à jour en production, n'est-ce pas?

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

Si vous mettez à jour vos bibliothèques, vous souhaitez é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é. S'il est modifié, cela signifie que vous avez une nouvelle version de quelque chose.

Le faire dans le référentiel vous assure que chaque développeur utilise les mêmes versions.

Pour les applications / projets : certainement oui.

La documentation du compositeur indique à ce sujet (avec accent):

Validez composer.lock de votre application (ainsi que composer.json) dans le contrôle de version.

Comme @meza l'a dit: vous devez valider le fichier de verrouillage afin que vous et vos collaborateurs travailliez sur le même ensemble de versions et vous empêchiez de dire comme "Mais cela a fonctionné sur mon ordinateur". ;-)

Pour les bibliothèques : probablement pas.

La documentation du compositeur note à ce sujet:

Remarque: 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 l'avoir fait dans les deux sens pour quelques projets, ma position est que cela composer.lockne devrait pas être engagé dans le cadre du projet.

composer.lockest construire des métadonnées qui ne font pas partie du projet. L'état des dépendances doit être contrôlé par la façon dont vous les versionnez (manuellement ou dans le cadre de votre processus de génération automatisé) et non arbitrairement 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 manquez de confiance dans votre schéma de version. 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 des dépendances a maintenant été implicitement définie.

De plus, votre projet ne devrait jamais avoir à être reconstruit ou à faire réacquérir ses dépendances dans chaque environnement, en particulier prod. Votre livrable (tar, zip, phar, un répertoire, etc.) doit être immuable et promu dans les environnements sans changer.

1. Vous ne devez pas mettre à jour vos dépendances directement sur Production.
2. Vous devez contrôler la version de votre fichier composer.lock .
3. Vous ne devez pas contrôler la version 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 bogues introduits avec les nouvelles dépendances, cela pourrait changer la façon dont le code se comporte affectant les vôtres, 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 devez contrôler la version de votre fichier composer.lock , 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é effectués avec du code spécifique. Ne pas se soucier de la version réelle du code que vous avez revient à télécharger des modifications de code dans 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 antérieure peut vous coûter cher.

L'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 façon, chaque fois que quelqu'un s'exécute composer install, il les installera de la même manière. 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 les mises à 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 fichier composer.json peut avoir ses propres dépendances requises comme répartiteur d'événements Symfony: 2. *. Avec ce type de configuration, vous pourriez vous retrouver avec Laravel 4.1.31 avec le répartiteur d'événements Symfony 2.4.1, et quelqu'un d'autre dans votre équipe pourrait avoir Laravel 4.1.31 avec le répartiteur d'événements 2.6.5, tout dépendrait du moment où était la dernière fois que vous avez exécuté l'installation de composer.

Ainsi, avoir votre fichier composer.lock dans le système de version stockera la version exacte de ces sous-dépendances, donc, lorsque vous et votre coéquipier effectuez une installation de compositeur (c'est la façon dont vous installerez vos dépendances basées sur un compositeur. verrouiller ) vous obtiendrez tous les deux les mêmes versions.

Et si vous voulez mettre à jour? Ensuite, dans votre environnement de développement, exécutez:, composer updatecela générera un nouveau fichier composer.lock (s'il y a quelque chose de nouveau) et après l'avoir testé, et test de QA et test de régression, testez-le et d'autres choses. 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 devez pas contrôler la version de vos dépendances réelles , car cela n'a aucun sens. Avec composer.lock, vous pouvez installer la version exacte des dépendances et vous n'avez pas besoin de 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 avez besoin de modifier l'un de ces éléments, vous devez le créer et y apporter vos modifications. Et si vous craignez d'avoir à récupérer les dépendances réelles à chaque génération ou publication, composer a différentes manières de résoudre ce problème, le cache, les fichiers zip, etc.

Vous validez ensuite le composer.jsonà 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 but du fichier de verrouillage est d'enregistrer les versions exactes qui sont installées afin 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 compositeur qui installe 1.2.4, puis valide le fichier composer.lock, lorsque vous composez l'installation, vous obtiendrez également 1.2.4, même si la version 1.3.0 a été publiée. Cela garantit que tous ceux qui travaillent sur le projet ont la même version exacte.

Cela signifie que si quelque chose a été validé depuis la dernière fois qu'une installation de composer a été effectuée, alors, sans fichier de verrouillage, vous obtiendrez un nouveau code tiers .

Encore une fois, c'est un problème si vous craignez la rupture de votre code. Et c'est l'une des raisons pour lesquelles il est important de considérer Composer comme étant centré autour du fichier composer.lock.

Source: Compositeur: Tout tourne autour du fichier de verrouillage .

Validez composer.lock de votre application (ainsi que 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 s'il l'est, il télécharge les versions qui y sont spécifiées (indépendamment de ce que composer.json dit). Cela signifie que toute personne qui configure le projet téléchargera la même version exacte des dépendances. Votre serveur CI, les machines de production, les autres développeurs de votre équipe, tout et tout le monde s'exécute sur les mêmes dépendances, ce qui atténue 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 certain que les dépendances installées fonctionnent toujours même si vos dépendances ont publié de nombreuses nouvelles versions depuis lors.

Source: Composer - Utilisation de base .

Si vous craignez la rupture de votre code, vous devez valider le composer.lockdans votre système de contrôle de version pour vous assurer que tous vos collaborateurs de projet utilisent la même version du code. Sans fichier de verrouillage, vous obtiendrez chaque fois un nouveau code tiers.

L'exception est lorsque vous utilisez une méta-applications, des bibliothèques dans lesquelles les dépendances doivent être mises à jour lors de l'installation (comme l'application Zend Framework 2 Skeleton ). L'objectif est donc de récupérer les dernières dépendances à chaque fois que vous souhaitez commencer à développer.

^{Source: Compositeur: tout tourne autour du fichier de verrouillage}

Voir aussi: Quelles sont les différences entre la mise à jour de Composer et l'installation de Composer?

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. Le compositeur pourrait étrangement l'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 utilisateurs extraient une lib du composeur peut souhaiter que cette lib utilise un verrou afin que les dépendances avec lesquelles la lib se charge soient testées.

D'un autre côté, cela augmente considérablement la charge 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 bibliothèque est susceptible d'avoir une version légèrement différente, vous avez besoin d'une prise en charge de plusieurs versions de bibliothèque et vous pouvez également voir rapidement la taille des dépendances nécessaires, d'où le conseil de la garder sur la feuille.

En tenant compte de cela, je ne trouve vraiment pas que les fichiers de verrouillage soient utiles, que ce soit des bibliothèques ou vos propres fichiers de travail. Il n'est utilisé que pour moi dans ma plate-forme de création / test, qui conserve tous les actifs acquis en externe uniquement en les mettant à jour 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é avec l'arborescence source, les arbres de construction seront soit ailleurs dans la structure VCS, soit gérés 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 pull peut apporter une masse d'actifs de construction. J'aime bien avoir tout dans un repo bien organisé à l'exception de la production / des informations d'identification sensibles et du ballonnement.

SVN peut le faire mieux que git car il ne vous oblige pas à acquérir l'intégralité du dépôt (bien que je soupçonne que ce n'est pas strictement nécessaire pour git non plus, mais le support est limité et il n'est pas couramment utilisé). Les dépôts de build simples ne sont généralement qu'une branche de superposition dans laquelle vous fusionnez / exportez l'arborescence de build. Certaines personnes combinent des ressources externes dans leur arbre source ou séparent d'autres arbres externes, de génération et de source. Il sert généralement à deux fins, la mise en cache des builds et les builds reproductibles, mais parfois le garder séparé à au moins un certain niveau permet également des builds frais / vides et des builds multiples facilement.

Il existe un certain nombre de stratégies pour cela et aucune d'entre elles ne fonctionne particulièrement bien avec la persistance de la liste des sources, sauf si vous conservez une source externe dans votre arborescence de sources.

Ils ont également des choses comme des hachages dans le fichier, comment cela fusionne-t-il lorsque deux personnes mettent à jour des packages? 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 où ils ont adopté une vision très spécifique et restrictive du problème. Vous voulez des versions répétables et des versions cohérentes? Incluez le dossier du fournisseur dans VCS. Ensuite, vous accélérez également la récupération des actifs et évitez de dépendre de ressources externes potentiellement cassées lors de la génération. Aucun des pipelines de création et de déploiement que je crée ne nécessite un accès externe, sauf si cela est 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 a du sens pour un système distribué, sauf comme mentionné précédemment, cela n'a aucun sens car cela se retrouverait avec un enfer de dépendance de bibliothèque pour les mises à jour de bibliothèque avec des conflits courants et des mises à jour aussi lentes que le plus lent à mettre à jour le package.

De plus, je mets à jour férocement. Chaque fois que je développe, je mets à jour et teste tout. Il y a une très très petite fenêtre pour qu'une dérive importante de la version se faufile. De manière réaliste aussi, lorsque le versioning sémantique est maintenu, ce qui tend à être pour le compositeur, vous n'êtes pas supposé avoir autant de problèmes de compatibilité ou de ruptures.

Dans composer.json, vous mettez les packages dont vous avez besoin et leurs versions. Vous pouvez y verrouiller les versions. Cependant, ces packages ont également 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 pouvez pas les mettre vous-même si vous voulez qu'elles soient verrouillées en version) donc quelqu'un d'autre exécutant composer install obtient quelque chose de différent sans le verrou. Vous pourriez ne pas vous en soucier beaucoup ou vous pourriez vous en soucier, cela dépend. Devriez-vous vous en soucier? Probablement au moins un peu, assez pour vous assurer que vous en êtes conscient dans n'importe quelle situation et impact potentiel, mais cela pourrait ne pas être un problème si vous avez toujours le temps de simplement exécuter DRY en premier et de réparer tout ce qui a été mis à jour.

Le compositeur de tracas essaie d'éviter parfois n'est tout simplement pas là et le tracas que les fichiers de verrouillage du compositeur peuvent créer est important. Ils n'ont absolument pas le droit de dire aux utilisateurs ce qu'ils doivent ou ne doivent pas faire en ce qui concerne les actifs de génération par rapport à la source (que ce soit pour rejoindre ou séparer dans VCS), car ce n'est pas leur affaire, ils ne sont ni votre patron ni moi. "Le compositeur dit" ce n'est pas une autorité, ce n'est pas votre officier supérieur et ils ne donnent aucune supériorité à personne à ce sujet. Vous seul connaissez votre situation réelle et ce qu'il y a de mieux pour cela. Cependant, ils pourraient conseiller une ligne de conduite par défaut pour les utilisateurs qui ne comprennent pas comment les choses fonctionnent, auquel cas vous voudrez peut-être suivre cela, mais personnellement, je ne pense pas que ' est un véritable substitut pour savoir comment les choses fonctionnent et être en mesure de bien répondre à vos besoins. En fin de compte, leur réponse à cette question est une meilleure supposition. Les personnes qui créent Composer ne savent pas où vous devez conserver votre composer.lock, pas plus qu'elles ne devraient le faire. 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 l'utilisabilité car le compositeur est très secret quant à savoir s'il utilise le verrouillage ou le JSON et n'est pas toujours bien d'utiliser les deux ensemble. Si vous exécutez l'installation, il utilise uniquement le fichier de verrouillage, il apparaîtrait donc si vous ajoutez quelque chose à composer.json, il ne sera pas installé car il n'est pas dans votre verrou. Ce n'est pas du tout intuitif ce que les opérations font vraiment et ce qu'elles font en ce qui concerne le fichier json / lock et parfois cela ne semble même pas logique (l'aide dit que l'installation prend un nom de package mais en essayant de l'utiliser, elle dit non ).

Pour mettre à jour le verrou ou appliquer des modifications à partir du json, vous devez utiliser la mise à jour et vous ne voudrez 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 toujours qu'un gâchis.

La mise à jour prend un âge, des concerts de RAM. Je soupçonne également que si vous prenez un projet qui n'a pas été touché depuis un certain temps, il ressemble aux versions qu'il a, ce qu'il y aura de plus en plus avec le temps et il ne fait probablement pas cela efficacement, ce qui l'étrangle.

Ils sont très sournois quand il s'agit d'avoir des commandes composites secrètes auxquelles vous ne pouvez pas vous attendre à être composites. Par défaut, la commande composer remove apparaît pour mapper la mise à jour du compositeur et le supprimer du compositeur par exemple.

La question que vous devez vraiment vous poser n'est pas de savoir si vous devez garder le verrou dans votre arbre source ou alternativement si vous devez le conserver quelque part ou non, mais plutôt vous devriez demander ce qu'il fait réellement, alors vous pouvez décider par vous-même quand vous devez persister et où.

Je soulignerai qu'avoir la capacité d'avoir le verrou est très pratique lorsque vous avez une stratégie de persistance de dépendance externe robuste car elle garde une trace de vous les informations utiles pour le suivre (les origines) et le mettre à 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 votre gorge comme option obligatoire pour qu'il pollue vos arbres sources. C'est une chose très courante à trouver dans les bases de code héritées où les gens ont apporté beaucoup de modifications à composer.json qui n'ont pas vraiment été appliquées et qui sont cassées lorsque les gens essaient d'utiliser composer. Aucun composeur.lock, aucun problème de désynchronisation.

Oui évidemment.

En effet, un compositeur installé localement donnera la préférence au fichier composer.lock par rapport à composer.json.

Si le fichier de verrouillage n'est pas disponible dans vcs, le composeur pointera vers le fichier composer.json pour installer les dernières dépendances ou versions.

Le fichier composer.lock maintient la dépendance plus en profondeur, c'est-à-dire qu'il pointe vers la validation réelle de la version du package que nous incluons dans notre logiciel, c'est donc l'un des fichiers les plus importants qui gère la dépendance plus finement.