¿Cuál es la mejor manera de desarrollar una biblioteca usando el compositor?

Estamos comenzando un nuevo proyecto y estamos gestionando dependencies con Composer. Probablemente buildemos nuestra aplicación encima de Laravel 4. Pero también crearemos nuestra propia biblioteca, que utilizaremos para todos nuestros próximos proyectos, no solo para este.

Entonces, tenemos esta terrible duda: ¿cuál es la mejor manera de desarrollar una biblioteca utilizando el compositor?

Si incluimos esa nueva biblioteca como una dependencia, cada vez que la modifiquemos tendremos que confirmar el cambio en el repository y luego llamar a la composer update .

¡Eso parece terrible!

¿Hay una mejor manera de hacer eso?

Creo que hay dos forms de manejar esto, que uso dependiendo del caso:

  • La biblioteca es una biblioteca pura, que es independiente, completamente probada, y la desarrolla usando TDD para garantizar que todo funcione. De esta forma, puede usarse con el ciclo "commit, update" que describiste muy bien, creo.
  • Está desarrollando un complemento o algo que debe integrarse en otra cosa (aplicación / framework) y probarlo de manera autónoma es más difícil, o lo está desarrollando muy estrechamente con su aplicación. En este caso, necesita la versión dev-master de la biblioteca para que Composer la instale con un clon git (si ya estaba instalada como una label, tendrá que rm -rf vendor/your/library para forzar una reinstallation en lugar de una actualización ) También puede forzar esto para lanzamientos labeldos usando el --prefer-source . Entonces, una vez que tenga un clon en el directory del proveedor, puede trabajar allí fácilmente. Si trabajas en un equipo, aún así tendrás que confirmarlo y luego actualizar para asegurarte de que los demás obtengan la última versión.

La tercera alternativa es simplemente desarrollar el código en el directory src / de su aplicación hasta que esté estabilizado y luego extraerlo como un package nuevo y agregarlo nuevamente como una dependencia, luego recurrir a las primeras dos forms que describí porque entonces será mucho más viable.

Si configura la dependencia de la twig principal del repository en lugar de un file de distribución empaquetado, Composer revisará una copy de trabajo en la carpeta de proveedores. Puede modificar esta copy de trabajo directamente en la carpeta de proveedores, como si fuera parte del proyecto principal, pero luego puede enviarla a su propio repository. Sin embargo, deberá asegurarse de composer update para mantener sincronizado el file composer.lock con el desarrollo de esa biblioteca.

Todavía es la forma más conveniente de desarrollar un proyecto en set con una dependencia.

Si su objective es desarrollar una biblioteca realmente impresionante, entonces debe tratar de desarrollarla independientemente de cualquier otro software que cree.

Debería cumplir una única tarea exacta. Y esto probablemente se hace después de algunas confirmaciones, por lo que la creación inicial de la biblioteca debería tomar solo una semana o dos para llegar a una primera versión estable. Y esta versión se puede labelr y luego usar en otro lugar.

Al labelr, intente estrictamente seguir las versiones semánticas : de esa manera puede usar la biblioteca con una restricción de versión como "~ 1.0", lo que significa al less la versión 1.0, pero todo lo que sea hasta 1.9999 es aceptable, siempre que no sea 2.0 (que significaría cambios incompatibles).

Y entonces realmente no necesita actualizar ningún otro software cuando lanza una nueva versión de la biblioteca. Solo necesita actualizar si desea include errores corregidos. Sin correcciones de errores, puede actualizar, pero no es necesario hacerlo inmediatamente después del lanzamiento de la nueva versión de la biblioteca.

Composer se ocupará de todas las dependencies que necesite. Lo más importante si inicia una nueva biblioteca es include el composer.json desde el inicio en el repository.

¿Qué sucede si realmente desea include siempre la última versión de la biblioteca en cada otro software que escriba? No estoy seguro de que te des count de las implicaciones que esto tiene. Significa que está vinculando estrictamente su otro software a la versión más reciente de la biblioteca. Rompe esa versión, o introduce un error desagradable, y se rompe todo tu software. Entonces, poder actualizar o no realmente es una característica. Descubrirá que todas las bibliotecas extranjeras que use seguirán el mismo mecanismo de publicación: marcan una nueva versión si se solucionó un error importante o si se implementó una cantidad razonable de características nuevas. No esperan que apruebe una nueva versión; debe aprobar su nueva versión en su software actualizando explícitamente a la más reciente. Y lo mismo debería aplicarse a una biblioteca interna.

Trata de evitar jugar con las soluciones "dev-master" mencionadas aquí. Podrían funcionar, pero Composer funciona mejor si se usa con versiones labeldas. Si tiene un estado razonablemente estable de su biblioteca, márquelo con "0.0.0" e incluya esa versión en todos lados en lugar de "dev-master". Y luego labelr según las reglas de la versión semántica.