Composer (il gestore delle dipendenze per PHP) e Packagist (il repository dei pacchetti PHP) sono due progetti nati e cresciuti in parallelo creati da Jordi Boggiano e Nils Adermann con il contributo di una numerosa comunità di sviluppatori. L'idea dietro Composer non è rivoluzionaria (progetti simili sono per esempio npm per NodeJS e Bundler per Ruby) ma diventa rivoluzionaria nell'ambito di PHP, dove il massimo per semplificare la gestione delle librerie di terze parti era PEAR. Il primo commit al repository pubblico su GitHub del sito Web di Packagist risale al giugno del 2011.
Composer semplifica il lavoro dello sviluppatore rendendo facile l'utilizzo di librerie di terze parti e potendo scegliere microlibrerie, focalizzate su un unico aspetto (fare una sola cosa e farla bene), a scapito di macrolibrerie che si occupano di fare tutto. Inoltre installa automaticamente le dipendenze delle librerie che dobbiamo usare, liberandoci da questa incombenza.
Composer si occupa anche degli aggiornamenti eseguibili tramite semplici comandi, tenendo sempre conto dei limiti che impostiamo nel file di configurazione. Infine ci fornisce una funzione per l'autocaricamento delle classi che può essere ottimizzata per l'ambiente di produzione.
Packagist è invece il repository pubblico al quale Composer fa riferimento di default per la ricerca delle librerie. Ad oggi conta 100 mila librerie installabili con oltre 500 mila versioni diverse, inoltre, presenta un'interfaccia grafica per la ricerca di librerie con cui trovare quello che serve in un unico database, evitando perdite di tempo.
In definitiva si tratta di due strumenti che devono essere conosciuti dallo sviluppatore PHP e che oggi rappresentano lo standard de facto per quanto riguarda l'installazione di liberie di terze parti. Nei prossimi capitoli vedremo come installare Composer, quali sono i suoi comandi più utili, come configurarlo manualmente, come ricercare una libreria su Packagist e come creare un server privato packagist-like.
La situazione prima di Composer
PHP ha avuto in passato dei limiti importanti legati alla programmazione ad oggetti, in parte essi sono stati superati grazie a PHP 5. Tra le limitazioni superate una delle più importanti riguarda i namespace, fondamentali nella programmazione ad oggetti perché permettono di raggruppare codice secondo logiche precise e di isolare classi con lo stesso nome ma con provenienze differenti, senza incompatibilità. Prima dei namespace si dovevano importare manualmente le classi con il rischio di un'incompatibilità per l'utilizzo di classi omonime ma diverse.
Alcuni progetti complessi facevano uso di convenzioni per sopperire a questa mancanza, per esempio generando nomi molto lunghi per le classi create, come Directory_AltraDirectory_NomeDellaClasse.
Rimaneva però un problema: come usare le proprie classi all'interno dei progetti? PHP è sempre stato molto flessibile non obbligando il programmatore a schemi rigidi: era possibile persino inserire tutte le proprie funzioni e classi all'interno di un unico file .php, importarlo e avere accesso a tutte le proprie librerie. Questo andava a scapito della manutenibilità del codice e la soluzione universalmente accettata è stata quella di usare un file per ogni classe, in questo modo però ogni file deve essere importato per poter utilizzare la classe dichiarata al suo interno.
Per ovviare a questo aspetto PHP offre sistemi per l'autocaricamento delle classi, per cui il manutentore di una libreria aggiunge al codice una funzione che si occupa di caricare tutte le classi, in questo modo l'utilizzatore finale deve importare un solo file comprendente l'autocaricamento per poter usare la libreria per intero. Sicuramente un passo avanti ma rimane ancora un problema: ogni libreria deve fare la stessa cosa rendendo poco agevole l'utilizzo di microlibrerie.
Il passaggio allo standard PSR-4
Nell'ottica di questa evoluzione del linguaggio, nel 2009 è nato il gruppo PHP-FIG (o il primo abbozzo di esso) con lo scopo di trovare metodi per l'interoperabilità tra framework (e librerie) diversi e stabilire linee guida, prassi e interfacce per l'interoperabilità conosciute con il nome di PSR (PHP Standard Recommendation).
La problematica dell'autocaricamento dei file è stata oggetto di 2 PSR, a cominciare dalla PSR-0 (oggi deprecata) che determinava proprio gli standard per l'autocaricamento.
L'attuale PSR-4 stabilisce che si possa associare un prefisso namespace (ad esempio Acme\Database) ad una directory base (ad esempio c:\php\acme-db). A seguito di questa mappatura ogni classe cercata in quel namespace verrà cercata anche all'interno della directory di base tramite un percorso costruito sulla base del namespace esteso. Seguendo l'esempio precedente, se si ha a disposizione una funzione per l'autocaricamento che segue lo standard PSR-4, la classe Acme\Database\Mysql verrà cercata nel file c:\php\acme-db\Mysql.php.
Ecco perché e come Composer genera per noi una funzione di autocaricamento che si occupa di tutti i pacchetti, con esso dobbiamo importare un solo file per poter accedere a tutte le librerie di cui abbiamo bisogno.