En un proyecto API, tenemos compositor.json configurado de la siguiente manera:
{
"require-dev": {
"phpunit/phpunit": "4.7.*"
},
"require": {
"monolog/monolog": "1.5.*"
}
}
Y a la primera composer installtodo estuvo bien. Phpunit funcionó cuando se invocó con vendor/bin/phpunit. Mi máquina de trabajo es un sistema operativo Windows 7, sin embargo, usamos git con este proyecto, y cuando trabajo en esto desde otra máquina (Kubuntu 14.04), después de hacerlo git pull, ya no puedo ejecutar pruebas unitarias vendor/bin/phpunit; falla con el error de que no puede busque proveedor/bin/phpunit.
En la máquina Linux, eliminé el ejecutable que no funcionaba proveedor/bin/phpunit, eliminé la carpeta proveedor/phpunit y pedí que Composer la reemplazara mediante composer update. En ese momento, puedo ejecutar pruebas unitarias nuevamente como antes. Sin embargo, esto no funciona tan perfectamente en Windows 7. Es más complicado.
Mi pregunta es: ¿Estoy haciendo algo mal al rastrear los archivos a través de github y luego trabajar en varios sistemas operativos? ¿Evitaría este error si solo realizara un seguimiento composer.jsony mantuviera el contenido del vendor/phpunit/phpunitdirectorio sin seguimiento (y dejara que los archivos permanecieran con su sistema operativo específico)? Gracias, Adán.
Respuesta1
El propósito de Composer es que solo tiene que tener un vendordirectorio vacío (!) en su repositorio, pero realizar un seguimiento composer.json(requisitos) y composer.lock(últimas versiones específicas probadas) y ejecutarlo composer installdespués del pago en una nueva máquina de desarrollo.
(NB. composer installinstalará las versiones específicas de acuerdo con el composer.lockarchivo. composer updateinstalará la última versión que coincida con los requisitos definidos en el composer.jsonarchivo).
Luego, Composer debería descargar el binario apropiado para su sistema y colocarlo en el vendor/bin/directorio.