Besserer WordPress-Code: Die Composer Lock-Datei
Bevor wir unsere Diskussion über Composer abschließen, müssen wir noch eine wichtige Sache besprechen: Das Vendor- Verzeichnis (und damit die Composer-Sperrdatei).
Insbesondere müssen wir darüber sprechen, warum wir das Anbieterverzeichnis nicht an das Repository übergeben müssen, sondern wie unsere Mitwirkenden sicher sein können, dass sie über die neueste Version der Software verfügen, die für die Arbeit mit unserer Codebasis erforderlich ist.
Die Verwendung von Tools zur Codequalität, um besseren WordPress-Code zu schreiben, ist wichtig, ja, aber es ist auch wichtig zu verstehen, wie man Abhängigkeiten und unser Repository richtig verwaltet. Bevor wir uns also diese Dienstprogramme ansehen, lassen Sie uns die Sperrdatei überprüfen, welche Rolle sie spielt und warum wir das Herstellerverzeichnis nicht in unser Repository übertragen müssen.
Besserer WordPress-Code mit der Composer Lock-Datei
Für diejenigen, die mit WordPress arbeiten – und vielleicht in anderen PHP-basierten Frameworks und Grundlagen (ich weiß es nicht wirklich, da ich eher nicht damit arbeite) – gibt es eine Abhängigkeit von Composer, was eine gute Sache ist.
Dies kann auch dazu führen, dass Sie die Quellcodeverwaltung des gesamten Anbieterverzeichnisses festschreiben möchten, was nicht gut ist.
Wie im vorigen Beitrag erwähnt :
Und ich empfehle nicht, das Herstellerverzeichnis in Ihr Repository einzuchecken. Das kann später zu einem riesigen Verzeichnis werden und den gesamten Zweck von Composer untergraben.
Wie können wir also sicherstellen, dass wir nicht unnötigerweise Dateien in das Repository übertragen (und damit die Größe unseres Repositorys aufblähen), während wir gleichzeitig sicherstellen, dass unsere Mitwirkenden dieselbe Version der Software verwenden wie wir?
Der Wunsch, das Lieferantenverzeichnis zu übernehmen
Für diejenigen unter Ihnen, die Composer ausgeführt haben und damit vertraut sind, zumindest das Herstellerverzeichnis zu sehen, sind Sie wahrscheinlich daran gewöhnt, mehrere Verzeichnisse mit installierten Abhängigkeiten zu sehen.
Und sie sind nützlich; sonst hättest du sie nicht aufgenommen, oder?
Aber hier ist die Sache mit dem Vendor – Verzeichnis: Selbst wenn Sie nur ein paar Abhängigkeiten mit Ihrem Projekt installiert haben, kann die Dateigröße selbst groß sein. Und das kann noch größer werden, wenn Sie viele Abhängigkeiten haben.
Unabhängig davon scheint es sinnvoll zu sein, dies der Quellcodeverwaltung zuzuweisen, oder? Wir möchten sicherstellen, dass alle die gleiche Version der Software haben, die wir verwenden, und wir möchten sicherstellen, dass sie sich nicht mit Composer auseinandersetzen müssen.
Es geht aber auch anders. Und es hält unser Repository klein und stellt gleichzeitig sicher, dass die Versionen unserer Abhängigkeiten mit denen synchron gehalten werden, die das Repository klonen, an das Repository übergeben oder für jedes Continuous-Integration-Dienstprogramm, das das Repository verwendet.
Die Sperrdatei verstehen
Bevor ich über das Vendor-Verzeichnis spreche, möchte ich einen weiteren wichtigen Aspekt von Composer ansprechen: die Lock-Datei. Das heißt, wenn Sie den Installations- oder den Update -Befehl in Ihrem Terminal ausführen, wird eine Sperrdatei zusammen mit dem Herstellerverzeichnis generiert .
Was ist diese Datei?
Der vorherige Beitrag zeigte eine Beispielkonfigurationsdatei. Eines der Dinge, die uns diese Datei auch ermöglicht, ist die Definition von Bibliotheken oder Abhängigkeiten von Drittanbietern, die wir in unseren Projekten verwenden können.
Ich habe in anderen Beiträgen darüber gesprochen (und wir können uns das später in dieser Serie etwas genauer ansehen). Aber hier kommt die Sperrdatei ins Spiel.
Kurz gesagt, die Sperrdatei enthält immer Informationen über die Version – die genaue Version – der Abhängigkeiten, die mit dem Projekt verwendet wurden, als die letzte Installation oder Aktualisierung ausgeführt wurde.
Wenn Composer die Installation abgeschlossen hat, schreibt es alle Pakete und die genauen Versionen davon, die es heruntergeladen hat, in die Datei composer.lock und sperrt das Projekt auf diese spezifischen Versionen.
Sie sollten die Datei composer.lock in Ihr Projektrepository übertragen, damit alle Personen, die an dem Projekt arbeiten, an dieselben Versionen von Abhängigkeiten gebunden sind (mehr unten).
Das Ziel ist sicherzustellen, dass jeder dieselbe Version der Abhängigkeiten des Projekts ausführt – nicht ältere Versionen, nicht neuere Versionen – sondern dieselbe Version.
Wenn Sie also Composer install ausführen, wenn eine Sperrdatei im Repository enthalten ist, wird die Version der Software verwendet, die in der Sperrdatei definiert ist.
Und dies stellt sicher, dass jeder dieselbe Version jeder Abhängigkeit ausführt, und kann somit verhindern, dass das Herstellerverzeichnis der Quellcodeverwaltung übergeben werden muss.
Höherwertigen Code schreiben
Wohin gehen wir von hier aus?
Nachdem wir nun verstanden haben, wie Composer und die Sperrdatei verwendet werden, können wir beginnen, über tatsächliche Abhängigkeiten zu sprechen, die zur Verbesserung unserer Codequalität beitragen.
Und wenn wir über das Schreiben von Code höherer Qualität sprechen, gibt es Dienstprogramme, die genau dafür gemacht sind. In den nächsten Beiträgen werden wir uns also einige davon ansehen.