Packagecaches integreren in optimize

Als je package eigen metadata vooraf genereert, is het foutgevoelig om gebruikers alleen te vragen een extra command aan hun deploymentprocedure toe te voegen: bij updates wordt die stap makkelijk vergeten. Met ServiceProvider::optimizes() kun je de commands voor het aanmaken en verwijderen opnemen in Laravels optimize en optimize:clear. Deze pagina bouwt voort op Laravel-packages ontwikkelen en bekijkt de implementatie van Laravel Framework v13.35.0. Het gaat hier niet om het formaat van cachebestanden, maar om de afspraken rond registratie en beheer.

Commands registreren en taken registreren zijn twee verschillende dingen

commands() registreert commandklassen die je via Artisan kunt aanroepen. optimizes() is een aparte stap die de namen van al uitvoerbare commands als optimalisatietaken registreert. Als je alleen optimizes() aanroept, worden de commandklassen niet geregistreerd. Het volgende voorbeeld gaat ervan uit dat het package al CacheMetadataCommand en ClearMetadataCommand bevat, met respectievelijk courier:cache en courier:clear-cache als $signature.

<?php

namespace Acme\Courier;

use Acme\Courier\Console\Commands\CacheMetadataCommand;
use Acme\Courier\Console\Commands\ClearMetadataCommand;
use Illuminate\Support\ServiceProvider;

class CourierServiceProvider extends ServiceProvider
{
    public function boot(): void
    {
        if ($this->app->runningInConsole()) {
            $this->commands([
                CacheMetadataCommand::class,
                ClearMetadataCommand::class,
            ]);

            $this->optimizes(
                optimize: 'courier:cache',
                clear: 'courier:clear-cache',
                key: 'acme-courier',
            );
        }
    }
}

Alle argumenten van optimizes() zijn nullable, dus je kunt ook alleen een aanmaak- of alleen een verwijdercommand registreren. Leg gebruikers in dat geval wel altijd uit met welke stap de gegenereerde cache ongeldig wordt gemaakt.

Ook de registratiesleutel is een afspraak met gebruikers

ServiceProvider slaat aanmaakcommands op in de statische array $optimizeCommands en verwijdercommands in $optimizeClearCommands. In beide gevallen wordt key de arraysleutel. Laat je key weg, dan wordt een naam afgeleid van de klassenaam van de provider. Voor CourierServiceProvider is dat bijvoorbeeld courier. Omdat alleen de klassenaam wordt gebruikt, kunnen providers met dezelfde naam in verschillende namespaces met elkaar botsen. Registreer je opnieuw onder dezelfde sleutel, dan wordt het command aan die kant overschreven door de latere waarde. Wil je meerdere taken registreren, geef dan verschillende sleutels op. Vermijd ook de sleutels van Laravels standaardtaken, zoals config en routes. Wanneer standaardtaken en packagetaken worden samengevoegd, worden gelijke stringsleutels namelijk eveneens overschreven.

Geef expliciet een sleutel op waaraan je package herkenbaar is, zoals acme-courier, en houd die gelijk tussen releases. De sleutel wordt de weergavenaam van de taak en is ook de waarde die gebruikers bij --except opgeven.

Packagetaken draaien na de standaardtaken

In de bekeken implementatie voegen beide commands de geregistreerde arrays van packages toe aan de array met standaardtaken en roepen ze die vervolgens op volgorde aan. Gebruik je een sleutel die niet botst, dan worden packagetaken na de standaardtaken toegevoegd.

Command	Volgorde van de standaardtaken	Daarna
`optimize`	`config:cache` → `event:cache` → `route:cache` → `view:cache`	Geregistreerde aanmaakcommands
`optimize:clear`	`config:clear` → `cache:clear` → `clear-compiled` → `event:clear` → `route:clear` → `view:clear`	Geregistreerde verwijdercommands

Ga uit van deze volgorde en laat het aanmaakcommand alleen de data genereren die het package zelf bezit, in plaats van andere standaardcaches opnieuw op te bouwen. Gebruik optimizes() niet als API om afhankelijkheden in volgorde tussen meerdere packages te regelen. Heb je een strikte volgorde nodig, zet de betreffende commands dan expliciet achter elkaar.

optimize:clear bevat ook cache:clear en verwijdert daarmee ook de data in de standaard cachestore. Wil je alleen de cache van het package wissen, voer dan courier:clear-cache rechtstreeks uit. Ontwerp ook het verwijdercommand van je package zo dat het niet de hele gedeelde store flusht, maar alleen de sleutels of bestanden verwijdert die het zelf bezit.

Uitsluiten op sleutel of commandnaam

De optie --except van beide commands accepteert kommagescheiden waarden. Van elke waarde wordt de witruimte aan het begin en eind verwijderd, en taken waarvan de sleutel of commandnaam overeenkomt, worden overgeslagen.

php artisan optimize --except=acme-courier
php artisan optimize --except=courier:cache
php artisan optimize:clear --except=acme-courier,cache

De eerste twee regels sluiten dezelfde aanmaaktaak uit. De derde sluit de verwijdertaak van het package en de standaardtaak cache:clear uit. cache is de sleutel van een taak en geen naam die specifiek voor het package is. Een uitsluiting geldt alleen voor die ene uitvoering. Het is geen instelling die de registratie in de provider uitschakelt of eerder aangemaakte packagecaches automatisch verwijdert.

Maak onderscheid tussen FAIL bij een taak en de exitcode van het bovenliggende command

OptimizeCommand en OptimizeClearCommand roepen elke taak aan met callSilently() en geven aan de taakweergave door of de exitcode 0 is. De normale uitvoer van het onderliggende command wordt niet getoond, dus om een oorzaak te onderzoeken voer je het eigen command rechtstreeks uit. In Laravel v13.35.0 geven beide handle()-methoden een niet-nul waarde van een onderliggend command niet door als returnwaarde van het bovenliggende command. Ook als FAIL op het scherm verschijnt, gaat de lus door, en zonder exception is de exitcode van het bovenliggende command 0. Een opgeworpen exception wordt daarentegen door de taakweergavecomponent opnieuw opgeworpen, dus daar geldt niet hetzelfde doorgaande gedrag.

Concludeer niet dat de packagecache succesvol is aangemaakt alleen omdat php artisan optimize met exitcode 0 eindigde. Dit gedrag is gebaseerd op de implementatie van de bekeken versie, dus controleer het opnieuw wanneer je de ondersteunde Laravel-versies bijwerkt.

Als het aanmaken van de packagecache een harde voorwaarde voor de deployment is, kies dan een procedure waarin je de exitcode van het onderliggende command direct kunt controleren. Het volgende voorbeeld sluit de packagetaak uit van de gezamenlijke uitvoering en voert die na de standaardtaken eenmaal rechtstreeks uit.

php artisan optimize --except=acme-courier && php artisan courier:cache

Dit voorbeeld laat een mislukte courier:cache doorwerken in de exitcode, maar vangt geen niet-nul exitcodes van de standaardtaken op. Moet je deployment ook die strikt detecteren, voer dan de benodigde commands afzonderlijk uit en controleer telkens de exitcode.

Caches ontwerpen en controleren die updates overleven

Leg naast de registratie ook de verantwoordelijkheden van de commands en van de code die de cache leest vast.

Aanmaken leidt bij herhaald uitvoeren met dezelfde invoer tot dezelfde toestand, en maakt bij een fout halverwege geen onvolledige data actief.
Verwijderen voltooit ook zonder fouten als er geen cache bestaat, en verwijdert geen door de gebruiker gepubliceerde configuratie of persistente data.
Een command waarvan het aanmaken mislukt, meldt een fout en geeft een niet-nul waarde terug. Ook de lezende code behandelt een beschadigde cache niet zonder meer als geldig.
Als je het cacheformaat wijzigt, vertel gebruikers dan dat ze de cache opnieuw moeten aanmaken en overweeg ook langlopende processen te herstarten.

Controleer naast de tests van het package ook het volgende in de applicatie die het package gebruikt. Omdat de registratiearrays statisch zijn, moet je er ook op letten dat de registratiestatus niet tussen tests in hetzelfde proces wordt meegenomen.

Te controleren handeling	Voorwaarde voor voltooiing
De eigen aanmaak- en verwijdercommands rechtstreeks uitvoeren	`0` bij succes, niet-nul bij een mislukte aanmaak. Verwijderen slaagt ook bij twee keer uitvoeren
`optimize` / `optimize:clear` uitvoeren	De packagetaken worden elk één keer aangeroepen en de toestand na aanmaken en verwijderen klopt
`--except` opgeven met sleutel en commandnaam	Alleen de betreffende taak wordt niet uitgevoerd
Het aanmaakcommand met niet-nul laten eindigen	Je kunt de `FAIL`-weergave onderscheiden van de exitcode van het bovenliggende command in de bekeken versie
Opnieuw aanmaken na een packageupdate	De cache wordt met de nieuwe code en configuratie aangemaakt en het oude formaat wordt niet meer gelezen

Gerelateerde pagina’s

Packageconfiguratie samenvoegen en cachen

Bekijk hoe gepubliceerde configuratie wordt aangevuld en hoe dat samenhangt met het opnieuw opbouwen van de configuratiecache.

Laravel-packages testen met Orchestra Testbench

Registreer providers en Artisan-commands in je testomgeving.

AI-ontwikkeling

Design patterns

Package-ontwikkeling

Applicatiestructuur

Nieuwe functies in Laravel 13

Eloquent in detail

Validatie-uitbreidingen

Authenticatie uitbreiden

Beveiliging

Queues

Testen

Realtime

Packagecaches integreren in optimize

Commands registreren en taken registreren zijn twee verschillende dingen

Ook de registratiesleutel is een afspraak met gebruikers

Packagetaken draaien na de standaardtaken

Uitsluiten op sleutel of commandnaam

Maak onderscheid tussen FAIL bij een taak en de exitcode van het bovenliggende command

Caches ontwerpen en controleren die updates overleven

Gerelateerde pagina’s

Packageconfiguratie samenvoegen en cachen

Laravel-packages testen met Orchestra Testbench

Geraadpleegde primaire bronnen

​Commands registreren en taken registreren zijn twee verschillende dingen

​Ook de registratiesleutel is een afspraak met gebruikers

​Packagetaken draaien na de standaardtaken

​Uitsluiten op sleutel of commandnaam

​Maak onderscheid tussen FAIL bij een taak en de exitcode van het bovenliggende command

​Caches ontwerpen en controleren die updates overleven

​Gerelateerde pagina’s

Packageconfiguratie samenvoegen en cachen

Laravel-packages testen met Orchestra Testbench

​Geraadpleegde primaire bronnen

Commands registreren en taken registreren zijn twee verschillende dingen

Ook de registratiesleutel is een afspraak met gebruikers

Packagetaken draaien na de standaardtaken

Uitsluiten op sleutel of commandnaam

Maak onderscheid tussen FAIL bij een taak en de exitcode van het bovenliggende command

Caches ontwerpen en controleren die updates overleven

Gerelateerde pagina’s

Geraadpleegde primaire bronnen