ServiceProvider::optimizes() binden Sie die Befehle zum Erzeugen und Löschen in Laravels optimize und optimize:clear ein.
Diese Seite setzt die Grundlagen der Paketentwicklung voraus und betrachtet die Implementierung in Laravel Framework v13.35.0. Es geht nicht um das Format der Cache-Dateien, sondern um die Vereinbarungen bei Registrierung und Betrieb.
Befehle und Tasks getrennt registrieren
commands() registriert Befehlsklassen, die Sie über Artisan aufrufen können. optimizes() ist ein separater Vorgang, der bereits ausführbare Befehlsnamen als Optimierungs-Tasks registriert. Rufen Sie nur Letzteres auf, werden die Befehlsklassen nicht registriert.
Das folgende Beispiel setzt voraus, dass das Paket bereits CacheMetadataCommand und ClearMetadataCommand implementiert und deren $signature jeweils courier:cache und courier:clear-cache lautet.
optimizes() sind nullable. Sie können also auch nur das Erzeugen oder nur das Löschen registrieren. Erklären Sie Ihren Nutzern in jedem Fall, mit welchem Schritt der erzeugte Cache invalidiert wird.
Auch der Registrierungsschlüssel ist eine Vereinbarung mit den Nutzern
ServiceProvider speichert Befehle zum Erzeugen im statischen Array $optimizeCommands und Befehle zum Löschen in $optimizeClearCommands. In beiden Fällen dient key als Array-Schlüssel.
Lassen Sie key weg, wird der Name aus dem Klassennamen des Providers abgeleitet. Aus CourierServiceProvider wird zum Beispiel courier. Da nur der Klassenname verwendet wird, können auch gleichnamige Provider aus unterschiedlichen Namespaces kollidieren.
Registrieren Sie denselben Schlüssel erneut, überschreibt der spätere Wert den Befehl auf der jeweiligen Seite. Wenn Sie mehrere Tasks registrieren möchten, verwenden Sie unterschiedliche Schlüssel. Vermeiden Sie außerdem die Schlüssel der Laravel-Standard-Tasks wie config oder routes. Auch beim Zusammenführen von Standard- und Paket-Tasks werden gleiche String-Schlüssel überschrieben.
Ausführung nach den Standard-Tasks
In der betrachteten Implementierung fügen beide Befehle das Registrierungs-Array der Pakete in das Array der Standard-Tasks ein und rufen die Einträge dann der Reihe nach auf. Bei kollisionsfreien Schlüsseln werden Paket-Tasks nach den Standard-Tasks angehängt.
Gehen Sie von dieser Reihenfolge aus: Ihr Befehl zum Erzeugen baut keine anderen Standard-Caches neu auf, sondern erzeugt nur die Daten, die Ihrem Paket gehören. Verwenden Sie
optimizes() nicht als API, um Abhängigkeiten zwischen mehreren Paketen zu steuern. Brauchen Sie eine strikte Reihenfolge, führen Sie die jeweiligen Befehle explizit nacheinander aus.
Nach Schlüssel oder Befehlsname ausschließen
Die Option--except beider Befehle nimmt kommagetrennte Werte entgegen. Leerzeichen vor und nach jedem Wert werden entfernt, und alle Tasks, deren Schlüssel oder Befehlsname übereinstimmt, werden ausgeschlossen.
cache:clear aus. cache ist dabei ein Task-Schlüssel und kein paketeigener Name.
Ein Ausschluss gilt nur für den jeweiligen Aufruf. Er deaktiviert weder die Registrierung im Provider, noch löscht er automatisch früher erzeugte Paket-Caches.
FAIL eines Tasks und Exit-Code des übergeordneten Befehls unterscheiden
OptimizeCommand und OptimizeClearCommand rufen jeden Task mit callSilently() auf und geben an die Task-Anzeige weiter, ob der Exit-Code 0 ist. Die normale Ausgabe der Unterbefehle wird nicht angezeigt. Um die Ursache eines Fehlers zu untersuchen, führen Sie den jeweiligen Befehl daher direkt aus.
In Laravel v13.35.0 geben beide handle()-Methoden einen von null verschiedenen Rückgabewert eines Unterbefehls nicht als eigenen Rückgabewert weiter. Auch wenn auf dem Bildschirm FAIL erscheint, läuft die Schleife weiter, und ohne Exception ist der Exit-Code des übergeordneten Befehls 0. Geworfene Exceptions werden dagegen von der Task-Anzeigekomponente erneut geworfen, sodass sich hier nicht dasselbe Fortsetzungsverhalten ergibt.
Ist das Erzeugen des Paket-Caches eine Voraussetzung für das Deployment, wählen Sie einen Ablauf, bei dem Sie den Exit-Code des Unterbefehls direkt prüfen können. Im folgenden Beispiel wird der Paket-Task aus dem Gesamtlauf ausgeschlossen und nach den Standard-Tasks genau einmal direkt ausgeführt.
courier:cache im Exit-Code wider, fasst aber keine von null verschiedenen Exit-Codes der Standard-Tasks zusammen. Müssen Sie in Ihrem Deployment auch Fehler der Standard-Tasks zuverlässig erkennen, führen Sie die benötigten Befehle einzeln aus und prüfen Sie jeweils den Exit-Code.
Update-sichere Caches entwerfen und prüfen
Legen Sie neben der Registrierung auch die Verantwortlichkeiten der Befehle und der lesenden Seite fest.- Das Erzeugen führt bei wiederholter Ausführung mit derselben Eingabe zum selben Zustand und aktiviert bei einem Abbruch keine unvollständigen Daten.
- Das Löschen schließt auch dann erfolgreich ab, wenn kein Cache existiert, und löscht weder veröffentlichte Konfigurationen der Nutzer noch persistente Daten.
- Ein Befehl, bei dem das Erzeugen fehlschlägt, meldet einen Fehler und gibt einen von null verschiedenen Wert zurück. Auch die lesende Seite behandelt einen beschädigten Cache nicht bedingungslos als gültig.
- Ändern Sie das Cache-Format, weisen Sie Nutzer darauf hin, dass der Cache neu erzeugt werden muss, und ziehen Sie auch einen Neustart lang laufender Prozesse in Betracht.
Verwandte Seiten
Paketkonfiguration zusammenführen und cachen
Wie das Ergänzen veröffentlichter Konfigurationen mit dem Neuaufbau des Konfigurations-Caches zusammenhängt.
Laravel-Pakete mit Orchestra Testbench testen
Provider und Artisan-Befehle in der Testumgebung registrieren.
Herangezogene Primärquellen
- Offizielle Laravel-Dokumentation: Optimize commands
- ServiceProvider: optimizes() und Registrierungsschlüssel
- OptimizeCommand: Tasks und Ausschlüsse
- OptimizeClearCommand: Lösch-Tasks und Ausführungsreihenfolge
- Command: Rückgabewert von handle() und Exit-Code
- Task: Ergebnisanzeige und erneutes Werfen von Exceptions