Dovrebbe essere impegnato compositore.lock per il controllo della versione?

Sono un po ‘confuso con composer.lock usato in un’applicazione con un repository.

Ho visto molte persone dire che non dovremmo .gitignore composer.lock dal repository.

Se aggiorno le mie librerie nel mio ambiente di sviluppo, avrò un nuovo composer.lock ma non sarò in grado di aggiornarle in produzione, vero?

Non genererà conflitti su questo file?

Se aggiorni le tue libs, vuoi impegnare anche il lockfile. In pratica afferma che il tuo progetto è bloccato su quelle specifiche versioni delle librerie che stai utilizzando.

Se si commettono le modifiche e qualcuno estrae il codice e aggiorna le dipendenze, il file di blocco non dovrebbe essere modificato. Se è modificato, significa che hai una nuova versione di qualcosa.

Averlo nel repository ti assicura che ogni sviluppatore sta utilizzando le stesse versioni.

Per applicazioni / progetti : Sicuramente sì.

La documentazione del compositore afferma su questo (con enfasi):

Configura il compositore.lock della tua applicazione (insieme a composer.json) nel controllo della versione.

Come @meza ha detto: dovresti impegnare il file di blocco in modo che tu ei tuoi collaboratori stiate lavorando sullo stesso set di versioni e impedite di dire “Ma ha funzionato sul mio computer”. 😉

Per le biblioteche : probabilmente no.

Le note della documentazione del compositore su questa materia:

Nota: per le librerie non è necessariamente consigliato il commit del file di blocco (…)

E afferma qui :

Per la tua libreria puoi impegnare il file compositore.lock se vuoi. Questo può aiutare il tuo team a testare sempre le stesse versioni di dipendenza. Tuttavia, questo file di blocco non avrà alcun effetto su altri progetti che dipendono da esso. Ha solo un effetto sul progetto principale.

Per le biblioteche sono d’accordo con la risposta di @Josh Johnson.

Dopo averlo fatto in entrambi i modi per alcuni progetti, la mia posizione è che composer.lock non dovrebbe essere impegnato come parte del progetto. So che è più facile farlo, ma ti prego di sopportare me mentre faccio un caso per questo.

composer.lock è costruito metadati che non fa parte del progetto. Lo stato delle dipendenze deve essere controllato attraverso il modo in cui le versioni vengono eseguite (manualmente o come parte del processo di compilazione automatizzata) e non arbitrariamente dall’ultimo sviluppatore per aggiornarle e eseguire il commit del file di blocco.

Se sei preoccupato che le tue dipendenze cambino tra gli aggiornamenti del compositore, allora hai una mancanza di fiducia nel tuo schema di controllo delle versioni. Le versioni (1.0, 1.1, 1.2, ecc.) Dovrebbero essere immutabili e dovresti evitare i caratteri jolly “dev-” e “X. *” al di fuori dello sviluppo della funzione iniziale.

Il commit del file di blocco è una regressione per il sistema di gestione delle dipendenze poiché la versione delle dipendenze è ora tornata ad essere definita implicitamente.

Inoltre, il tuo progetto non dovrebbe mai essere ricostruito o avere le dipendenze necessarie in ogni ambiente, specialmente prod. Il tuo deliverable (tar, zip, phar, una directory, ecc.) Dovrebbe essere immutabile e promosso attraverso gli ambienti senza cambiare stato.

Edit: Sapevo che questa non sarebbe stata una risposta popolare, ma se hai votato per il basso sarebbe abbastanza gentile da fornire un motivo nei commenti che sottolinea la falla nella risposta? Grazie!

  1. Non dovresti aggiornare le tue dipendenze direttamente su Produzione.
  2. Dovresti controllare la versione del tuo file composer.lock .
  3. Non dovresti controllare la versione delle tue dipendenze reali.

1. Non dovresti aggiornare le tue dipendenze direttamente su Produzione , perché non sai come questo influenzerà la stabilità del tuo codice. Potrebbero esserci bug introdotti con le nuove dipendenze, potrebbe cambiare il modo in cui il codice si comporta da solo, potrebbe essere incompatibile con altre dipendenze, ecc. Dovresti farlo in un ambiente di sviluppo, seguendo il QA e il test di regressione, ecc. .

2. Dovresti controllare la versione del tuo file composer.lock , perché questo memorizza informazioni sulle tue dipendenze e sulle dipendenze delle tue dipendenze che ti permetteranno di replicare lo stato corrente del codice. Questo è importante perché, tutti i test e lo sviluppo sono stati eseguiti su un codice specifico. Non preoccuparti della versione attuale del codice che hai è simile al caricamento delle modifiche al codice dell’applicazione e non alla verifica. Se stai aggiornando le versioni delle tue dipendenze, questo dovrebbe essere un atto volontario, e dovresti fare tutto il ansible per assicurarti che tutto funzioni ancora. Perdere una o due ore di tempo per tornare a una versione precedente potrebbe costare un sacco di soldi.

Uno degli argomenti che vedrai sul non aver bisogno di composer.lock è che puoi impostare la versione esatta di cui hai bisogno nel tuo file composer.json , e che in questo modo, ogni volta che qualcuno esegue l’ composer install , li installerà lo stesso codice. Questo non è vero, perché le tue dipendenze hanno le loro dipendenze e la loro configurazione potrebbe essere specificata in un formato che consente aggiornamenti alle sovversioni o forse anche a intere versioni.

Ciò significa che anche quando si specifica che si desidera Laravel 4.1.31 nel proprio compositore.json , nel suo file composer.json , Laravel potrebbe avere le proprie dipendenze richieste come Symfony event-dispatcher: 2. *. Con questo tipo di configurazione, potresti finire con Laravel 4.1.31 con Symfony event-dispatcher 2.4.1, e qualcun altro del tuo team potrebbe avere Laravel 4.1.31 con dispatcher di eventi 2.6.5, tutto dipenderebbe da quando è stata l’ultima volta che hai eseguito l’installazione del compositore.

Quindi, avere il tuo file composer.lock nel sistema di versioni memorizzerà la versione esatta di queste dipendenze secondarie, così, quando tu e il tuo compagno di squadra fate un’installazione di compositore (questo è il modo in cui installerete le vostre dipendenze basate su un compositore. lock ) entrambi otterrete le stesse versioni.

Cosa succede se vuoi aggiornare? Quindi nel tuo ambiente di sviluppo esegui: composer update , questo genererà un nuovo file composer.lock (se c’è qualcosa di nuovo) e dopo averlo testato, e test e regressione del QA lo testano e roba. Puoi spingerlo a tutti gli altri per scaricare il nuovo compositore.lock , poiché è sicuro aggiornarlo.

3. Non dovresti controllare la versione delle tue dipendenze reali , perché non ha senso. Con il compositore.lock è ansible installare la versione esatta delle dipendenze e non è necessario impegnarle. Perché dovresti aggiungere al repository 10000 file di dipendenze, quando non dovresti aggiornarli. Se hai bisogno di cambiare una di queste cose, devi forarla e apportare le modifiche lì. E se sei preoccupato di dover recuperare le dipendenze effettive ogni volta di una build o di un rilascio, il compositore ha diversi modi per alleviare questo problema, cache, file zip, ecc.

Quindi si configura composer.json al progetto e tutti gli altri membri del team possono eseguire l’installazione di composer per installare le dipendenze del progetto.

Il punto del file di blocco è di registrare le esatte versioni installate in modo che possano essere reinstallate. Ciò significa che se hai una versione spec di 1. * e il tuo collega esegue l’aggiornamento del compositore che installa 1.2.4, e poi esegue il commit del file composer.lock, quando installerai il compositore, otterrai anche 1.2.4, anche se 1.3.0 è stato rilasciato. Ciò garantisce che tutti coloro che lavorano al progetto abbiano la stessa identica versione.

Ciò significa che se qualcosa è stato commesso dall’ultima volta che è stata eseguita un’installazione di compositore, quindi, senza un file di blocco, si otterrà il nuovo codice di terze parti abbattuto .

Ancora una volta, questo è un problema se sei preoccupato per il tuo codice di rottura. Ed è uno dei motivi per cui è importante pensare a Composer come centrato attorno al file composer.lock.

Fonte: compositore: è tutto sul file di blocco .


Configura il compositore.lock della tua applicazione (insieme a composer.json) nel controllo della versione. Questo è importante perché il comando install controlla se è presente un file di blocco e, in caso affermativo, scarica le versioni specificate lì (indipendentemente da ciò che dice compositore.json). Ciò significa che chiunque configuri il progetto scaricherà la stessa identica versione delle dipendenze. Il tuo server CI, le macchine di produzione, gli altri sviluppatori del tuo team, tutto e tutti funzionano con le stesse dipendenze, il che riduce il potenziale di bug che interessano solo alcune parti delle distribuzioni. Anche se si sviluppa da solo, in sei mesi, quando si reinstalla il progetto, si può avere la certezza che le dipendenze installate funzionino ancora anche se da quel momento le proprie dipendenze hanno rilasciato molte nuove versioni.

Fonte: compositore – utilizzo di base .

Se sei preoccupato per la rottura del tuo codice, devi impegnare il composer.lock nel tuo sistema di controllo della versione per garantire che tutti i tuoi collaboratori del progetto stiano utilizzando la stessa versione del codice. Senza un file di blocco, si otterrà ogni volta il nuovo codice di terze parti.

L’eccezione è quando si utilizzano meta app, librerie in cui le dipendenze devono essere aggiornate all’installazione (come l’ app Skeleton di Zend Framework 2 ). Quindi l’objective è quello di afferrare le ultime dipendenze ogni volta che si vuole iniziare lo sviluppo.

Fonte: compositore: è tutto sul file di blocco

Vedi anche: quali sono le differenze tra l’aggiornamento del compositore e l’installazione del compositore?