
Em um projeto de API, temos o compositor.json definido como o seguinte:
{
"require-dev": {
"phpunit/phpunit": "4.7.*"
},
"require": {
"monolog/monolog": "1.5.*"
}
}
E, no início, composer install
estava tudo bem. Phpunit funcionou quando invocado com vendor/bin/phpunit
. Minha máquina de trabalho é um sistema operacional Windows 7, porém usamos git com este projeto, e quando trabalho nisso em outra máquina (Kubuntu 14.04), depois de fazer isso git pull
, não consigo mais executar testes de unidade vendor/bin/phpunit
- ele falha com um erro que não pode encontre fornecedor/bin/phpunit.
Na máquina Linux, excluí o executável não funcional vendor/bin/phpunit, removi a pasta vendor/phpunit e fiz com que o compositor o substituísse por composer update
. Nesse ponto, posso executar testes de unidade novamente como antes. No entanto, isso não funciona perfeitamente no Windows 7. É mais complicado.
Minha pergunta é: estou fazendo algo errado ao rastrear os arquivos pelo github e depois trabalhar em vários sistemas operacionais? Eu evitaria esse erro se apenas acompanhasse composer.json
e mantivesse o conteúdo do vendor/phpunit/phpunit
diretório não rastreado (e deixasse os arquivos permanecerem em seu sistema operacional específico)? Obrigado, Adão.
Responder1
O objetivo do Composer é que você apenas precisa ter um vendor
diretório vazio (!) Em seu repositório, mas rastrear composer.json
(requisitos) e composer.lock
(últimas versões específicas testadas) e executar composer install
após o checkout em uma nova máquina de desenvolvimento.
(Observação: composer install
instalará as versões específicas de acordo com o composer.lock
arquivo. composer update
instalará a versão mais recente que corresponda aos requisitos definidos no arquivo composer.json
.)
O Composer deve então baixar o binário apropriado para o seu sistema e colocá-lo no vendor/bin/
diretório.