ServiceProvider::optimizes() puoi integrare i comandi di generazione ed eliminazione in optimize e optimize:clear di Laravel.
Questa pagina presuppone le basi dello sviluppo di pacchetti ed esamina l’implementazione di Laravel Framework v13.35.0. Non tratta il formato dei file di cache, ma il contratto di registrazione e di gestione operativa.
Separare la registrazione dei comandi da quella dei task
commands() registra le classi di comando richiamabili da Artisan. optimizes() è un’operazione distinta, che registra come task di ottimizzazione nomi di comandi già eseguibili. Chiamare solo quest’ultimo non registra le classi di comando.
L’esempio seguente presuppone che il pacchetto implementi già CacheMetadataCommand e ClearMetadataCommand, con $signature rispettivamente courier:cache e courier:clear-cache.
optimizes() sono nullable, quindi puoi registrare anche solo la generazione o solo l’eliminazione. In ogni caso, indica sempre agli utenti con quale procedura invalidare la cache generata.
Anche la chiave di registrazione è un contratto con gli utenti
ServiceProvider salva i comandi di generazione nell’array statico $optimizeCommands e quelli di eliminazione in $optimizeClearCommands. In entrambi i casi la key diventa la chiave dell’array.
Se ometti key, il nome viene generato dal nome della classe del provider. Per esempio, CourierServiceProvider diventa courier. Poiché viene usato solo il nome della classe, possono verificarsi collisioni anche con provider omonimi in namespace diversi.
Se registri di nuovo la stessa chiave, il comando di quel lato viene sovrascritto dal valore successivo. Se vuoi registrare più task, specifica chiavi diverse. Evita inoltre le chiavi dei task standard di Laravel, come config o routes: quando i task standard e quelli dei pacchetti vengono uniti, le chiavi stringa identiche vengono sovrascritte.
Esecuzione dopo i task standard
Nell’implementazione esaminata, entrambi i comandi espandono l’array dei pacchetti registrati nell’array dei task standard e poi li richiamano in sequenza. Se usi una chiave che non va in collisione, i task del pacchetto vengono aggiunti dopo quelli standard.
Tenendo conto di quest’ordine, il comando di generazione non deve ricostruire le altre cache standard, ma generare solo i dati di proprietà del pacchetto. Non usare
optimizes() come API per controllare le dipendenze di ordine tra più pacchetti: se ti serve un ordine rigoroso, elenca esplicitamente i comandi dedicati.
Esclusione per chiave o per nome del comando
L’opzione--except di entrambi i comandi accetta valori separati da virgole. Rimuove gli spazi iniziali e finali di ciascun valore ed esclude i task la cui chiave o il cui nome di comando corrisponde.
cache:clear standard. cache è la chiave di un task, non un nome specifico del pacchetto.
L’esclusione vale solo per quell’esecuzione. Non è un’impostazione che disattiva la registrazione nel provider né che elimina automaticamente una cache del pacchetto creata in precedenza.
Distinguere il FAIL di un task dal codice di uscita del comando padre
OptimizeCommand e OptimizeClearCommand richiamano ciascun task con callSilently() e passano alla visualizzazione del task l’informazione se il codice di uscita è 0. Poiché l’output normale dei comandi figli non viene mostrato, per indagare sulla causa esegui direttamente il comando dedicato.
In Laravel v13.35.0, i metodi handle() di entrambi i comandi non restituiscono come valore di ritorno del padre il valore diverso da zero di un comando figlio. Anche se a schermo compare FAIL, il ciclo prosegue e, in assenza di eccezioni, il codice di uscita del comando padre è 0. Le eccezioni lanciate, invece, vengono rilanciate dal componente di visualizzazione dei task, quindi il comportamento non è lo stesso.
Se la generazione del pacchetto è un requisito obbligatorio del deploy, usa una procedura in cui puoi controllare direttamente il codice di uscita del comando figlio. Per esempio, il codice seguente esclude il task del pacchetto dall’esecuzione complessiva e lo esegue direttamente una sola volta dopo i task standard.
courier:cache, ma non aggrega le uscite con valore diverso da zero dei task standard. Nei deploy in cui devi rilevare rigorosamente anche quelle, esegui singolarmente i comandi necessari e controlla i rispettivi codici di uscita.
Progettare e verificare una cache che regga agli aggiornamenti
Oltre alla registrazione, definisci anche le responsabilità dei comandi e del codice che legge la cache.- La generazione, anche se eseguita più volte, porta allo stesso stato a partire dallo stesso input e non attiva dati incompleti in caso di errore a metà.
- L’eliminazione termina correttamente anche se la cache non esiste e non elimina la configurazione pubblicata né i dati persistenti degli utenti.
- Un comando di generazione che fallisce segnala l’errore e restituisce un valore diverso da zero. Anche il codice di lettura non deve trattare incondizionatamente come valida una cache corrotta.
- Se modifichi il formato della cache, informa gli utenti della necessità di rigenerarla e valuta anche il riavvio dei processi a lunga esecuzione.
Pagine correlate
Merge e cache della configurazione dei pacchetti
Scopri come si integra la configurazione pubblicata e il rapporto con la ricostruzione della cache della configurazione.
Testare pacchetti Laravel con Orchestra Testbench
Registra provider e comandi Artisan nell’ambiente di test.
Fonti primarie consultate
- Documentazione ufficiale di Laravel: Optimize commands
- ServiceProvider: optimizes() e chiavi di registrazione
- OptimizeCommand: task ed esclusioni
- OptimizeClearCommand: task di eliminazione e ordine di esecuzione
- Command: valore di ritorno di handle() e codice di uscita
- Task: visualizzazione del risultato e rilancio delle eccezioni