¿Debería composer.lock comprometerse con el control de versiones?

Estoy un poco confundido con composer.lock usado en una aplicación con un repository.

Vi a mucha gente diciendo que no deberíamos .gitignore composer.lock del repository.

Si actualizo mis bibliotecas en mi entorno de desarrollo, tendré un nuevo composer.lock pero no podré actualizarlas a producción, ¿o sí?

¿No generará conflictos en este file?

Si actualiza sus libs, también quiere confirmar el file de locking. Básicamente indica que su proyecto está bloqueado a esas versiones específicas de las bibliotecas que está utilizando.

Si confirma los cambios y alguien extrae su código y actualiza las dependencies, el file de locking no debe modificarse. Si se modifica, significa que tienes una nueva versión de algo.

Tenerlo en el repository le asegura que cada desarrollador está usando las mismas versiones.

Para aplicaciones / proyectos : Definitivamente sí.

La documentation del compositor indica esto (con énfasis):

Commita el composer.lock de su aplicación (junto con composer.json) en el control de versiones.

Como dijo @meza: Debes enviar el file de locking para que tú y tus queueboradores trabajen en el mismo set de versiones y te impidan decir "pero funcionó en mi computadora". 😉

Para bibliotecas : Probablemente no.

Las notas de documentation del compositor sobre este asunto:

Nota: para las bibliotecas, no se recomienda necesariamente confirmar el file de locking (…)

Y estados aquí :

Para su biblioteca, puede enviar el file composer.lock si lo desea. Esto puede ayudar a su equipo a probar siempre contra las mismas versiones de dependencia. Sin embargo, este file de locking no tendrá ningún efecto en otros proyectos que dependen de él. Solo tiene un efecto en el proyecto principal.

Para las bibliotecas, estoy de acuerdo con la respuesta de @Josh Johnson.

Después de hacerlo en ambos sentidos para algunos proyectos, mi postura es que composer.lock no debe comprometerse como parte del proyecto. Sé que es más fácil hacerlo, pero por favor tengan paciencia conmigo mientras hago un caso para esto.

composer.lock es metadata de compilation que no es parte del proyecto. El estado de las dependencies debe controlarse a través de cómo las está versionando (ya sea manualmente o como parte de su process de compilation automatizado) y no arbitrariamente por el último desarrollador para actualizarlas y confirmar el file de locking.

Si le preocupa que sus dependencies cambien entre las actualizaciones del compositor, entonces tiene una falta de confianza en su esquema de control de versiones. Las versiones (1.0, 1.1, 1.2, etc.) deben ser inmutables y debe evitar los comodines "dev-" y "X. *" fuera del desarrollo de características inicial.

Comprometerse con el file de locking es una regresión para su sistema de administración de dependencies ya que la versión de dependencia ahora ha vuelto a ser implícitamente definida.

Además, su proyecto nunca debería tener que ser reconstruido o tener sus dependencies requeridas en cada entorno, especialmente prod. Su entregable (tar, zip, phar, un directory, etc.) debe ser inmutable y promoverse a través de entornos sin cambiar el estado.

Editar: Sabía que esto no sería una respuesta popular, pero si votas de plano, ¿serías tan amable de dar una razón en los comentarios que señale el error en la respuesta? ¡Gracias!

  1. No debe actualizar sus dependencies directamente en Producción.
  2. Debe controlar la versión de su file composer.lock .
  3. No debe controlar la versión de sus dependencies reales.

1. No debe actualizar sus dependencies directamente en Production , porque no sabe cómo afectará esto a la estabilidad de su código. Podría haber errores introducidos con las nuevas dependencies, podría cambiar la forma en que se comporta el código afectando al suyo, podría ser incompatible con otras dependencies, etc. Debería hacer esto en un entorno de desarrollo, seguido por un control de calidad adecuado y testings de regresión, etc. .

2. Debería controlar la versión de su file composer.lock , porque almacena información sobre sus dependencies y sobre las dependencies de sus dependencies que le permitirán replicar el estado actual del código. Esto es importante porque todas las testings y el desarrollo se han realizado contra un código específico. No preocuparse por la versión real del código que tiene es similar a cargar cambios de código en su aplicación y no probarlos. Si está actualizando sus versiones de dependencies, esto debería ser un acto voluntario, y debe tomar las precauciones necesarias para asegurarse de que todo siga funcionando. Perder una o dos horas de time invertido volviendo a una versión anterior podría costarle mucho dinero.

Uno de los arguments que verá al no necesitar el composer.lock es que puede establecer la versión exacta que necesita en su file composer.json , y que de esta manera, cada vez que alguien ejecute la composer install , los instalará el mismo código Esto no es cierto, porque sus dependencies tienen sus propias dependencies, y su configuration puede especificarse en un formatting que permita actualizaciones a subversiones, o incluso versiones enteras.

Esto significa que incluso cuando especifica que desea Laravel 4.1.31 en su composer.json , Laravel en su file composer.json puede tener sus propias dependencies requeridas como Symfony event-dispatcher: 2. *. Con este tipo de configuration, podrías terminar con Laravel 4.1.31 con Symfony event-despacher 2.4.1, y alguien más en tu equipo podría tener Laravel 4.1.31 con event-dispatcher 2.6.5, todo dependería de cuándo fue la última vez que ejecutó la installation del compositor.

Por lo tanto, tener su file composer.lock en el sistema de versiones almacenará la versión exacta de estas subdependencies, por lo tanto, cuando usted y su compañero de equipo hagan una installation de compositor (esta es la manera en que instalará sus dependencies basándose en un compositor). locking ) ambos obtendrán las mismas versiones.

¿Qué pasa si quieres actualizar? Luego, en su entorno de desarrollo ejecute: la composer update , esto generará un nuevo file composer.lock (si hay algo nuevo) y después de probarlo, y la testing de QA y la regresión lo testingn y esas cosas. Puede presionar para que todos los demás descarguen el nuevo composer.lock , ya que es seguro actualizarlo.

3. No debe controlar la versión de sus dependencies reales , porque no tiene sentido. Con composer.lock puedes instalar la versión exacta de las dependencies y no necesitarás confirmarlas. ¿Por qué debería agregar a su repository 10000 files de dependencies, cuando se supone que no debe actualizarlos? Si necesita cambiar algo de esto, debe bifurcarlo y hacer sus cambios allí. Y si le preocupa tener que search las dependencies reales cada vez que se comstack o libera, el compositor tiene diferentes forms de solucionar este problema: caching, files zip, etc.

A continuación, asigna el composer.json a su proyecto y todos los demás en su equipo pueden ejecutar la installation del compositor para instalar las dependencies de su proyecto.

El objective del file de locking es registrar las versiones exactas que están instaladas para que puedan volverse a instalar. Esto significa que si tiene una versión especificada de 1. * y su compañero de trabajo ejecuta la actualización del compositor que instala 1.2.4, y luego confirma el file composer.lock, cuando instale el compositor, también obtendrá 1.2.4, incluso si 1.3.0 ha sido lanzado. Esto asegura que todos los que trabajen en el proyecto tengan la misma versión exacta.

Esto significa que si se ha cometido algo desde la última vez que se realizó una installation del compositor, entonces, sin un file de locking, se obtendrá un nuevo código de terceros que se networkingucirá .

De nuevo, esto es un problema si le preocupa que se rompa el código. Y es una de las razones por las que es importante pensar que Composer está centrado en el file composer.lock.

Fuente: Compositor: todo se trata del file de locking .


Commita el composer.lock de su aplicación (junto con composer.json) en el control de versiones. Esto es importante porque el command de installation comtesting si hay un file de locking presente y, si lo está, descarga las versiones especificadas allí (independientemente de lo que diga el compositor.json). Esto significa que cualquiera que configure el proyecto downloadá la misma versión exacta de las dependencies. Su server de CI, máquinas de producción, otros desarrolladores en su equipo, todo y todos se ejecutan en las mismas dependencies, lo que mitiga el potencial de errores que afectan solo a algunas partes de las implementaciones. Incluso si se desarrolla solo, en seis meses, al reinstalar el proyecto, puede estar seguro de que las dependencies instaladas siguen funcionando incluso si sus dependencies lanzaron muchas versiones nuevas desde entonces.

Fuente: Compositor – Uso básico .

Si le preocupa que se rompa el código, debe asignar composer.lock a su sistema de control de versiones para asegurarse de que todos los queueboradores de su proyecto estén usando la misma versión del código. Sin un file de locking, obtendrá un código de terceros nuevo cada vez.

La exception es cuando usa metaaplicaciones, bibliotecas donde las dependencies deben actualizarse durante la installation (como la Zend Framework 2 Skeleton App ). Por lo tanto, el objective es get las últimas dependencies cada vez que desee comenzar a desarrollar.

Fuente: Compositor: Todo se trata del file de locking

Ver también: ¿Cuáles son las diferencias entre la actualización del compositor y la installation del compositor?