Ich bin ein wenig verwirrt mit composer.lock in einer Anwendung mit einem Repository verwendet werden.
Ich habe viele Leute gesehen, die sagten, wir sollten nicht .gitignore composer.lock aus dem Repository.
Wenn ich meine Bibliotheken in meiner Entwicklungsumgebung aktualisiere, habe ich eine neue composer.lock aber ich werde nicht in der Lage sein, sie in der Produktion zu aktualisieren, oder?
Entstehen dadurch nicht Konflikte mit dieser Datei?
Wenn Sie sich Sorgen machen, dass Ihr Code beschädigt werden könnte, sollten Sie die composer.lock in Ihr Versionskontrollsystem ein, um sicherzustellen, dass alle Ihre Projektmitarbeiter dieselbe Version des Codes verwenden. Ohne eine Sperrdatei wird jedes Mal neuer Code von Dritten heruntergeladen.
Die Ausnahme ist, wenn Sie eine Meta-Applikation verwenden, Bibliotheken, deren Abhängigkeiten bei der Installation aktualisiert werden sollen (wie die Zend Framework 2 Skelett-Anwendung ). Ziel ist es also, jedes Mal, wenn Sie mit der Entwicklung beginnen wollen, die neuesten Abhängigkeiten zu nutzen.
Quelle: Komponist: Alles über die Sperrdatei
Siehe auch: Was sind die Unterschiede zwischen composer update und composer install?
Ja, natürlich.
Das liegt daran, dass ein lokal installierter Composer die Datei composer.lock gegenüber composer.json bevorzugt.
Wenn die Lock-Datei nicht in vcs verfügbar ist, wird der Composer auf die composer.json-Datei verweisen, um die neuesten Abhängigkeiten oder Versionen zu installieren.
Die Datei composer.lock verwaltet die Abhängigkeiten in größerer Tiefe, d.h. sie verweist auf den aktuellen Commit der Version des Pakets, das wir in unsere Software einbinden, daher ist dies eine der wichtigsten Dateien, die die Abhängigkeiten feiner behandelt.
Diese Frage wurde hier in diesem Thema bereits ausführlich beantwortet.
Auf jeden Fall sollten Sie die vc composer.lock
aber was ich jetzt erzählen werde, ist die Warum
composer.json ist der Einstiegspunkt der Abhängigkeitsmanifest für die php-Pakete.
hat sie den Paketentwicklern vorgeschrieben, dass sie folgen semantische Versionierung .
Wenn also die API-Version (x) in x.y.z geändert wurde, werden Sie verstehen, dass es Dinge gibt, um die Sie sich kümmern müssen, oder Sie können Ihre Version auf einige "~x" versión.
Aber es gab eine Menge Pakete, die sich nicht an die Regel hielten (5.3 & 5.4 api levels geändert oder gebrochen):
composer hat eine Lösung gefunden: eine weitere Datei zum Sperren der Paketversionen. (composer.lock)
Sie enthält die genauen Paketversionen, so dass jeder, der die derselbe Abhängigkeitsversionen können davon profitieren.
Es ist erwähnenswert, dass eine der 12 Faktor moderne Web-Entwicklungsprinzipien ist es, die Abhängigkeiten in allen Deployments gleich zu halten, so dass jedes Deployment getestet werden kann. und es würde keine Kontraktion zwischen ihnen geben.
für diese:
Sie müssen das composer.lock unter Versionskontrolle halten
und auf die Produktion gerecht:
composer install --no-devinstallieren Sie alles aus Ihrer vc-gesteuerten Sperrdatei. die deps haben Sie vorher komplett getestet.
die composer.json ist eine schlanke Datei für die Entwickler um Rückschlüsse auf die Deps und die Version zu ziehen.
während die composer.lock ist für die Verwendung durch die setzt ein. (Maschine) zur Installation der genau Versionsnummern auf dem Einsatz.
es ist wie die Analogie für die ip & domains :
ip (Sperrdatei) für die Verwendung durch Maschinen
Bereich (json), der für die menschliche Nutzung bestimmt ist
Jedoch können sowohl Menschen (Entwickler) als auch Maschinen (Entwickler) beide Versionen lesen und davon profitieren, aber es gibt eine bevorzugte Version für jeden von ihnen.
Darauf gibt es keine genaue Antwort.
Im Allgemeinen sollte Composer nicht das tun, was das Build-System tun sollte, und Sie sollten composer.lock nicht in VCS einfügen. Composer könnte es seltsamerweise verkehrt herum haben. Endbenutzer und nicht Produzenten sollten keine Lock-Dateien verwenden. Normalerweise behält Ihr Build-System Snapshots, wiederverwendbare Verzeichnisse, etc. und nicht jedes Mal ein leeres Verzeichnis. Leute, die eine Lib aus dem Composer auschecken, möchten vielleicht, dass diese Lib eine Sperre verwendet, damit die Abhängigkeiten, die die Lib lädt, gegen die sie getestet wurde.
Auf der anderen Seite erhöht sich dadurch der Aufwand für die Versionsverwaltung erheblich, da man mit Sicherheit mehrere Versionen jeder Bibliothek haben möchte, da die Abhängigkeiten streng geregelt sind. Wenn jede Bibliothek wahrscheinlich eine etwas andere Version hat, dann braucht man Unterstützung für mehrere Bibliotheksversionen und man kann auch schnell sehen, wie die Größe der benötigten Abhängigkeiten ausufert, daher der Rat, sie auf dem Blatt zu halten.
In Anbetracht dessen halte ich Sperrdateien weder in Bibliotheken noch in Ihren eigenen Arbeitsverzeichnissen für sinnvoll. Es ist nur Verwendung für mich ist in meinem Build/Test-Plattform, die alle extern erworbenen Vermögenswerte persistiert nur aktualisieren sie, wenn angefordert, bietet wiederholbare Builds für die Prüfung, Build und Bereitstellung. Während dies im VCS gespeichert werden kann, wird es nicht immer zusammen mit dem Quellcode-Baum aufbewahrt. Die Build-Bäume befinden sich entweder an anderer Stelle in der VCS-Struktur oder werden von einem anderen System irgendwo anders verwaltet. Wenn sie in einem VCS gespeichert sind, ist es fraglich, ob man sie im selben Repo wie die Quellbäume aufbewahren sollte, da sonst jeder Pull eine Masse an Build-Assets mit sich bringen kann. Ich mag es, alles in einem übersichtlichen Repo zu haben, mit Ausnahme von produktiven/sensiblen Credentials und Blähungen.
SVN kann das besser als Git, da es Sie nicht zwingt, das gesamte Repository zu erwerben (obwohl ich vermute, dass das für Git auch nicht unbedingt nötig ist, aber die Unterstützung dafür ist begrenzt und wird nicht häufig verwendet). Einfache Build-Repos sind in der Regel nur ein Overlay-Zweig, in den man den Build-Tree zusammenführt/exportiert. Manche Leute kombinieren externe Ressourcen in ihrem Quellbaum oder trennen weitere, externe, Build- und Quellbäume. Normalerweise dient dies zwei Zwecken, dem Caching von Builds und wiederholbaren Builds, aber manchmal erlaubt die Trennung zumindest auf einer Ebene auch frische/blanke Builds und mehrere Builds auf einfache Weise.
Dafür gibt es eine Reihe von Strategien, von denen keine besonders gut mit der Persistenz der Quellenliste funktioniert, es sei denn, Sie behalten externe Quellen in Ihrem Quellbaum.
Sie haben auch Dinge wie Hashes in der Datei, wie wird das zusammengeführt, wenn zwei Leute Pakete aktualisieren? Das allein sollte Ihnen zu denken geben, dass dies vielleicht falsch interpretiert wird.
Die Argumente, die die Leute für Sperrdateien vorbringen, sind Fälle, in denen sie eine sehr spezifische und restriktive Sicht des Problems haben. Sie wollen wiederholbare Builds und konsistente Builds? Binden Sie den Vendor-Ordner in das VCS ein. Dann beschleunigen Sie auch das Abrufen von Assets und sind während des Builds nicht von potentiell defekten externen Ressourcen abhängig. Keine der von mir erstellten Build- und Deployment-Pipelines erfordert externen Zugriff, es sei denn, es ist absolut notwendig. Wenn man eine externe Ressource aktualisieren muss, dann nur einmal und nur einmal. Was Composer zu erreichen versucht, macht Sinn für ein verteiltes System, aber wie bereits erwähnt, macht es keinen Sinn, weil es mit einer Hölle von Bibliotheksabhängigkeiten für Bibliotheksaktualisierungen enden würde, mit häufigen Konflikten und Aktualisierungen, die so langsam sind wie das am langsamsten zu aktualisierende Paket.
Außerdem aktualisiere ich eifrig. Jedes Mal, wenn ich entwickle, aktualisiere und teste ich alles. Es gibt nur ein sehr, sehr kleines Zeitfenster, in dem sich eine signifikante Versionsabweichung einschleichen kann. Realistisch betrachtet, wenn die semantische Versionierung eingehalten wird, was bei Composer der Fall ist, sollte man nicht so viele Kompatibilitätsprobleme oder Brüche haben.
In composer.json tragen Sie die benötigten Pakete und deren Versionen ein. Sie können die Versionen dort sperren. Allerdings haben diese Pakete auch Abhängigkeiten mit dynamischen Versionen, die nicht von composer.json gesperrt werden (obwohl ich nicht verstehe, warum Sie sie nicht auch selbst dort eintragen können, wenn Sie wollen, dass sie gesperrt werden), so dass jemand anderes, der composer install ausführt, etwas anderes ohne die Sperre erhält. Es kann sein, dass Ihnen das egal ist, oder es kann Ihnen nicht egal sein, es kommt darauf an. Sollte es Sie interessieren? Wahrscheinlich zumindest ein wenig, genug, um sicherzustellen, dass Sie sich in jeder Situation der möglichen Auswirkungen bewusst sind, aber es könnte auch kein Problem sein, wenn Sie immer die Zeit haben, zuerst einen DRY-Lauf durchzuführen und alles zu reparieren, das aktualisiert wurde.
Der Ärger, den der Komponist zu vermeiden versucht, ist manchmal einfach nicht da, und der Ärger, den das Sperren von Dateien durch den Komponisten verursachen kann, ist erheblich. Sie haben absolut kein Recht, den Nutzern vorzuschreiben, was sie in Bezug auf Build- und Source-Assets tun oder nicht tun sollen (ob sie sich im VCS zusammenschließen oder trennen sollen), denn das geht sie nichts an, sie sind nicht der Boss von dir oder mir. "Composer sagt" ist keine Autorität, sie sind weder Ihr Vorgesetzter noch geben sie irgendjemandem irgendeine Überlegenheit zu diesem Thema. Nur Sie kennen Ihre wirkliche Situation und wissen, was das Beste für Sie ist. Es kann jedoch sein, dass sie Benutzern, die nicht wissen, wie die Dinge funktionieren, eine Standardvorgehensweise empfehlen, die Sie vielleicht befolgen sollten, aber ich persönlich glaube nicht, dass dies ein wirklicher Ersatz dafür ist, zu wissen, wie die Dinge funktionieren und in der Lage zu sein, Ihre Anforderungen richtig zu erarbeiten. Letztendlich ist die Antwort auf diese Frage nur eine Vermutung. Die Leute, die den composer herstellen, wissen nicht, wo Sie Ihr composer.lock aufbewahren sollen, und sie sollten es auch nicht. Ihre einzige Verantwortung ist es, Ihnen zu sagen, was es ist und was es tut. Darüber hinaus müssen Sie selbst entscheiden, was für Sie am besten ist.
Das Beibehalten der Lock-Datei ist problematisch für die Benutzerfreundlichkeit, weil der Composer sehr geheimnisvoll ist, ob er Lock oder JSON verwendet und nicht immer beide zusammen verwendet. Wenn man install ausführt, verwendet es nur die Lock-Datei, so dass es scheint, dass wenn man etwas zu composer.json hinzufügt, es nicht installiert wird, weil es nicht in der Lock-Datei ist. Es ist überhaupt nicht intuitiv, was die Operationen wirklich tun und was sie in Bezug auf die json/lock-Datei tun und manchmal scheinen sie nicht einmal Sinn zu machen (die Hilfe sagt, dass install einen Paketnamen nimmt, aber wenn man versucht, es zu benutzen, sagt es nein).
Um die Sperre zu aktualisieren oder grundsätzlich Änderungen aus der json-Datei zu übernehmen, müssen Sie update verwenden, und Sie möchten vielleicht nicht alles aktualisieren. Das Schloss hat Vorrang bei der Auswahl dessen, was installiert werden soll. Wenn es eine Sperrdatei gibt, wird sie verwendet. Sie können die Aktualisierung etwas einschränken, aber das System ist immer noch ein einziges Durcheinander.
Die Aktualisierung dauert eine Ewigkeit, Gigabytes an RAM. Ich vermute auch, wenn Sie ein Projekt abholen, die nicht für eine Weile berührt wurde, dass es von den Versionen sah es oben hat, die es mehr im Laufe der Zeit sein wird und es wahrscheinlich nicht tun, dass effizient, die nur stranguliert es.
Sie sind sehr, sehr raffiniert, wenn es darum geht, geheime zusammengesetzte Befehle zu haben, von denen man nicht erwarten könnte, dass sie zusammengesetzt sind. Standardmäßig scheint der Befehl composer remove zum Beispiel composer update und composer remove zuzuordnen.
Die Frage, die Sie sich wirklich stellen müssen, ist nicht, ob Sie die Sperre in Ihrem Quellbaum aufbewahren sollten oder ob Sie sie irgendwo auf irgendeine Art und Weise aufbewahren sollten oder nicht, sondern Sie sollten sich fragen, was sie eigentlich tut, dann können Sie selbst entscheiden, wann Sie sie aufbewahren müssen und wo.
Ich werde darauf hinweisen, dass die Möglichkeit, die Sperre ist eine große Bequemlichkeit, wenn Sie eine robuste externe Abhängigkeit Persistenz-Strategie, wie es hält den Überblick über Sie die Informationen nützlich für die Verfolgung, dass (die Ursprünge) und die Aktualisierung, aber wenn Sie nicht dann ist es weder hier noch dort. Es ist nicht nützlich, wenn es Ihnen als obligatorische Option aufgezwungen wird, damit es Ihre Quellbäume verschmutzt. Es ist eine sehr häufige Sache, die man in alten Codebasen findet, wo Leute viele Änderungen an composer.json gemacht haben, die nicht wirklich angewendet wurden und kaputt sind, wenn Leute versuchen, composer zu benutzen. Kein composer.lock, kein Desync-Problem.
Für jeden, der mit Heroku arbeitet, ist die Antwort klar: "Ja, es sollte committed werden":
Si
composer.jsongibt Abhängigkeiten jeglicher Art in seinemrequireAbschnitt, der entsprechendecomposer.lockdie durch die Ausführung voncomposer updatemuss ebenfalls an das Repository übergeben werden, sonst wird der Push abgelehnt.
Quelle: Heroku PHP-Unterstützung: Freischaltung .
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
