> ## Documentation Index
> Fetch the complete documentation index at: https://kawax.biz/llms.txt
> Use this file to discover all available pages before exploring further.

# Packagecaches integreren in optimize

> Gebruik optimizes() in Laravel 13 om het aanmaken en verwijderen van de eigen caches van je package in de deployment te integreren. Aan de hand van de implementatie: registratiesleutels, uitsluitingen, uitvoeringsvolgorde en exitcodes bij fouten.

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](/nl/advanced/package-development) 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 theme={null}
<?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.

<Tip>
  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.
</Tip>

## 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 |

```mermaid theme={null}
flowchart TD
    A["boot() van de provider"] --> B["Artisan-commands registreren met commands()"]
    A --> C["Sleutel en commandnamen registreren met optimizes()"]
    B --> D["php artisan optimize"]
    C --> D
    D --> E["Standaardconfiguratie, events, routes en views cachen"]
    E --> F["courier:cache uitvoeren"]
    C --> G["php artisan optimize:clear"]
    G --> H["Standaardcaches verwijderen"]
    H --> I["courier:clear-cache uitvoeren"]
```

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.

<Warning>
  `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.
</Warning>

## 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.

```bash theme={null}
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.

<Warning>
  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.
</Warning>

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.

```bash theme={null}
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

<Columns cols={2}>
  <Card title="Packageconfiguratie samenvoegen en cachen" icon="sliders" href="/nl/advanced/package-config-merging">
    Bekijk hoe gepubliceerde configuratie wordt aangevuld en hoe dat samenhangt met het opnieuw opbouwen van de configuratiecache.
  </Card>

  <Card title="Laravel-packages testen met Orchestra Testbench" icon="flask" href="/nl/advanced/package-testing">
    Registreer providers en Artisan-commands in je testomgeving.
  </Card>
</Columns>

## Geraadpleegde primaire bronnen

* [Officiële Laravel-documentatie: Optimize commands](https://github.com/laravel/docs/blob/13.x/packages.md#optimize-commands)
* [ServiceProvider: optimizes() en registratiesleutels](https://github.com/laravel/framework/blob/v13.35.0/src/Illuminate/Support/ServiceProvider.php)
* [OptimizeCommand: taken en uitsluitingen](https://github.com/laravel/framework/blob/v13.35.0/src/Illuminate/Foundation/Console/OptimizeCommand.php)
* [OptimizeClearCommand: verwijdertaken en uitvoeringsvolgorde](https://github.com/laravel/framework/blob/v13.35.0/src/Illuminate/Foundation/Console/OptimizeClearCommand.php)
* [Command: returnwaarde van handle() en exitcode](https://github.com/laravel/framework/blob/v13.35.0/src/Illuminate/Console/Command.php)
* [Task: weergave van resultaten en opnieuw opwerpen van exceptions](https://github.com/laravel/framework/blob/v13.35.0/src/Illuminate/Console/View/Components/Task.php)


## Related topics

- [Laravel-packages ontwikkelen](/nl/advanced/package-development.md)
- [Geavanceerde onderwerpen](/nl/advanced/index.md)
- [Bestandsopslag](/nl/filesystem.md)
- [Notificatiekanaal - LINE SDK for Laravel](/nl/packages/laravel-line-sdk/notification.md)
- [Eloquent-observers en modelevents](/nl/advanced/eloquent-observers.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.