Plug-ins de testing y debugging

Estoy desarrollando un instalador de compositor personalizado para software propietario y no estoy muy seguro de cómo debo probarlo y depurarlo.

Composer carga complementos solo cuando se especifica como dependencia, por lo que creo un proyecto de testing que define el complemento como una dependencia, como esta:

{ //... "repositories": [ { "type":"git", "url":"/path/to/gitrepo" } ], "require":{ "myvendor/my-plugin":"dev-master" } } 

El problema es que el compositor usa solo la última versión comprometida, lo que significa que si quiero probar algo, tengo que hacerlo primero. Esto lleva a una gran cantidad de compromisos de cambio de una línea "inútiles" (como "ah, olvidé una coma allí"), que realmente no quiero tener en mi historial de git repo.

Supongo que tiene que haber una mejor manera, pero no encontré ninguna. Lo ideal sería definir un directory como un repository (que sería el mi directory de trabajo), pero hasta donde yo sé, no hay nada como un repository de tipo "directory".

Simplemente puede editar el código del package del proveedor localmente. Cuando el compositor posterior desee actualizar este package, le preguntará cómo tratar con los files modificados. En ese caso, simplemente puede elegir s para ocultar sus cambios. También vea este stackoverflow para aclarar el significado de las opciones disponibles.

Después de actualizar el package, sus cambios se volverán a aplicar.

Ver la pantalla para un dialog de ejemplo: enter image description here

Para este propósito, uso tags y --force push para el repository de la biblioteca. Entonces en mi proyecto tengo algo así como

 { //... "repositories": [ { "type":"git", "url":"/path/to/gitrepo" } ], "require":{ "myvendor/my-plugin":"dev-tag" } } 

Cuando hago algunos cambios en mi repository de la biblioteca, retengo el último compromiso con dev-tag tag y luego

 git push origin master --force --tags 

Así que mi label es actual para la última confirmación de la biblioteca. Después de eso lo hago solo

 composer update 

Y tengo todo el código de la biblioteca en mi proyecto.

¡No use este flujo de trabajo con las tags utilizadas en el código de producción!