Codice WordPress migliore: il file di blocco del compositore
Prima di concludere la nostra discussione su Composer, abbiamo ancora una cosa importante da discutere: la directory del fornitore (e, per estensione, il file di blocco di Composer).
In particolare, dobbiamo parlare del motivo per cui non è necessario eseguire il commit della directory del fornitore nel repository, ma di come i nostri contributori possono essere sicuri di disporre dell’ultima versione del software necessaria per funzionare con la nostra base di codice.
L’utilizzo di strumenti di qualità del codice per scrivere un codice WordPress migliore è importante, sì, ma è importante anche capire come gestire correttamente le dipendenze e il nostro repository. Quindi, prima di esaminare tali utilità, esaminiamo il file di blocco, il ruolo che svolge e perché non è necessario eseguire il commit della directory del fornitore nel nostro repository.
Codice WordPress migliore con il file di blocco del compositore
Per coloro che lavorano con WordPress – e forse in altri framework e fondazioni basati su PHP (non lo so proprio perché tendo a non lavorare con loro) – c’è una dipendenza da Composer, che è una buona cosa.
Ciò può anche portare a voler impegnare l’intero controllo del codice sorgente della directory del fornitore, il che non è una buona cosa.
Come accennato nel post precedente :
E non consiglio di controllare la directory del fornitore nel tuo repository. Questo può diventare un’enorme directory in seguito e può minare l’intero scopo di Composer.
Quindi, come possiamo assicurarci di non inviare file inutilmente (e quindi gonfiare le dimensioni del nostro repository) nel repository assicurandoci che i nostri contributori utilizzino la nostra stessa versione del software?
Il desiderio di impegnare l’elenco dei fornitori
Per quelli di voi che hanno eseguito Composer e hanno familiarità con almeno la visualizzazione della directory del fornitore, è probabile che siate abituati a vedere più directory di dipendenze installate.
E sono utili; altrimenti non li avresti inclusi, giusto?
Ma ecco il problema della directory del fornitore : anche se hai solo alcune dipendenze installate con il tuo progetto, la dimensione del file stesso può essere grande. E questo può essere ancora più grande quando hai molte dipendenze.
Indipendentemente da ciò, impegnarsi nel controllo del codice sorgente sembra avere senso, giusto? Vogliamo assicurarci che tutti abbiano la stessa versione del software che stiamo utilizzando e vogliamo assicurarci che non debbano avere a che fare con Composer.
C’è un altro modo, però. E mantiene piccolo il nostro repository assicurandoci anche che le versioni delle nostre dipendenze siano sincronizzate con coloro che clonano il repository, si impegnano nel repository o per qualsiasi utilità di integrazione continua che utilizza il repository.
Comprendere il file di blocco
Prima di parlare della directory del fornitore, voglio toccare un altro aspetto importante di Composer: il file di blocco. Cioè, se esegui il comando install o update nel tuo terminale, vedrai un file di blocco generato insieme alla directory del fornitore.
Cos’è questo file?
Il post precedente mostrava un file di configurazione di esempio. Una delle cose che questo file ci consente anche di fare è definire librerie di terze parti, o dipendenze, che possiamo utilizzare nei nostri progetti.
Ne ho parlato in altri post (e possiamo esaminarlo un po’ più avanti in questa serie). Ma è qui che entra in gioco il file di blocco.
In breve, il file di blocco contiene sempre informazioni sulla versione – la versione esatta – delle dipendenze utilizzate con il progetto l’ultima volta che è stata eseguita l’ installazione o l’ aggiornamento.
Quando Composer ha terminato l’installazione, scrive tutti i pacchetti e le versioni esatte di essi che ha scaricato nel file composer.lock, bloccando il progetto su quelle versioni specifiche.
Dovresti eseguire il commit del file composer.lock nel repository del tuo progetto in modo che tutte le persone che lavorano al progetto siano bloccate sulle stesse versioni delle dipendenze (più sotto).
L’obiettivo è assicurarsi che tutti eseguano la stessa versione delle dipendenze del progetto, non versioni precedenti, né versioni più recenti, ma la stessa versione.
Pertanto, quando si esegue Composer, l’installazione quando un file di blocco è incluso nel repository utilizzerà la versione del software definita nel file di blocco.
E questo garantisce che tutti eseguano la stessa versione di ciascuna dipendenza e quindi può prevenire la necessità di eseguire il commit della directory del fornitore al controllo del codice sorgente.
Scrivere codice di qualità superiore
Allora dove andiamo da qui?
Ora che abbiamo capito come utilizzare Composer e come utilizzare il file di blocco, possiamo iniziare a parlare delle effettive dipendenze che aiutano a migliorare la qualità del nostro codice.
E quando parliamo di scrivere codice di qualità superiore, ci sono utilità fatte proprio per questo. Quindi nei prossimi post ne esamineremo alcuni.