La configurazione di Composer non si limita a quanto visto fino ad ora ma permette una serie di personalizzazioni che vanno dalla semplice modifica delle directory di destinazione delle parti del progetto all'impostazione di opzioni di sicurezza, dalla definizione di una versione specifica di PHP, in modo da eseguire un controllo su quello che sarà l'ambiente reale dove dovrà girare l'applicazione, fino alla gestione della cache dei pacchetti.
Questo genere di impostazioni vengono configurate tramite la sezione config del file composer.json del progetto. La sintassi è semplice dato che si tratta di coppie chiave/valore con il valore che può essere una stringa o un hash a seconda del caso:
{
...
config: {
"opzione-1": "valore",
"opzione-2": "valore2"
}
}Nell'articolo verranno evidenziate le impostazioni che verosimilmente saranno più utilizzate.
Comandi di Composer
Alcuni comandi di Composer permettono una modifica di un comportamento sulla base di alcuni parametri di configurazione. Abbiamo visto che è possibile forzare la creazione di un autoloader ottimizzato tramite il comando:
composer dump-autoload --optimize
Impostando l'opzione optimize-autoloader su true ogni volta che dovrà essere generato l'autoloader (ad ogni install, update, require e remove) verrà ottimizzato automaticamente. Ad esempio questa opzione può essere comoda per un team numeroso o per progetti definiti che dovranno subire un deploy su vari server o ancora, banalmente, per non dimenticare l'ottimizzazione.
A volte, anche se raramente, può capitare che il processo di installazione di un pacchetto non arrivi a conclusione per sopraggiunto timeout nel download dello stesso. Potrebbe dipendere da una connessione particolarmente lenta o da un repository di grandi dimensioni. In questi casi è possibile porre rimedio aggiungendo l'impostazione process-timeout che richiede come valore il numero di secondi necessari a generare un errore di timeout. Il valore di default è 300, corrispondente a 5 minuti.
Per progetti complessi può essere necessario importare un alto numero di pacchetti di dipendenze. Questo può tradursi in una lunga attesa necessaria alla risoluzione dei conflitti e delle dipendenze ma può generare anche una certa confusione sui pacchetti realmente richiesti nel file di configurazione. Se i pacchetti vengono aggiunti tramite il comando composer require è possibile fare in modo che questi vengano ordinati per nome tramite l'opzione sort-packages impostata su true.
Personalizzare le directory di destinazione
I comportamenti di Composer si basano su una serie di standard e convenzioni che possono andare bene per la maggior parte dei progetti, come la cartella di destinazione delle librerie di dipendenza dell'ambiente di sviluppo convenzionalmente impostata su vendor. Questo permette di gestire in maniera ottimale le dipendenze e, ad esempio, non includerle nei nostri sistemi di versioning (git, vcs, etc.), ci basterà aggiungere al repository il file di configurazione di Composer per ricostruire tutto l'albero di dipendenze sulle macchine di sviluppo e produzione.
Composer permette di impostare la cartella di destinazione dei file sorgente dei pacchetti scaricati tramite l'impostazione vendor-dir che richiede come valore un path assoluto o relativo alla cartella in cui si trova il file di configurazione.
In maniera analoga è possibile impostare la directory che conterrà gli eseguibili (o meglio i link agli eseguibili) che i singoli pacchetti forniscono. Di default questa cartella è bin all'interno della root del progetto, ma è possibile personalizzarla tramite l'opzione bin-dir.
Sempre in tema di eseguibili il comportamento di default è quello di installare unicamente quelli relativi al sistema operativo in uso, per cui su sistemi Linux non saranno creati i link ai file .bat dedicati agli ambienti Windows. Normalmente questa configurazione può essere corretta, ma in casi particolari come ad esempio un computer di sviluppo in dual boot o l'utilizzo di un un ambiente di virtualizzazione con virtual machine Linux da un host Windows, può essere comodo avere a disposizione gli eseguibili per entrambi i sistemi. Per fare questo basta impostare l'opzione bin-compat con il valore full.
Gestione della cache
Dalla versione 1.2.0 Composer supporta l'utilizzo di una cache di sistema per l'installazione dei pacchetti. Questa funzionalità velocizza il recupero di pacchetti soprattutto sulle macchine di sviluppo o su server web che contengono numerosi progetti. Tramite il file di configurazione è possibile modificare il comportamento di questa componente in ogni aspetto.
Di default Composer salva nella cache di sistema tutti i pacchetti che scarica e poi periodicamente elimina quelli meno utilizzati (con la data di ultimo utilizzo meno recente) fino ad occupare un massimo di 300Mb di dati. Tramite l'opzione cache-files-maxsize è possibile aumentare o diminuire questo valore, ad esempio impostandolo a 500MiB.
Sempre relativamente al garbage collector della funzionalità di cache, è possibile specificare il tempo dall'ultimo utilizzo necessario perché il file scaricato e salvato in cache venga cancellato, indipendentemente dalla dimensione complessiva della stessa tramite l'opzione di configurazione cache-files-ttl. Il valore impostato in secondi può essere incrementato o diminuito rispetto al default di 6 mesi (15552000 secondi) mentre l'impostazione di questo valore a zero disabilita la funzionalità.
Infine è possibile personalizzare la directory utilizzata per il caching dei pacchetti tramite l'opzione cache-dir che richiede come valore il path della directory da utilizzare. Di default questa è impostata nella home directory di un singolo utente e dovrebbe essere modificata esclusivamente in casi particolari, come ad esempio la creazione di una cache unica condivisa tra tutti gli utenti del sistema.