1

In an API project, we have composer.json set to the following:

{
    "require-dev": {
        "phpunit/phpunit": "4.7.*"
    },
     "require": {
        "monolog/monolog": "1.5.*"
    }
}

And, upon the first composer install everything was fine. Phpunit worked when invoked with vendor/bin/phpunit. My work machine is a Windows 7 OS, however we use git with this project, and when I work on this from another machine (Kubuntu 14.04), after doing git pull, I can no longer run unit tests with vendor/bin/phpunit - it fails with error that it cannot find vendor/bin/phpunit.

On the linux machine, I deleted the non-functioning executable vendor/bin/phpunit, and removed vendor/phpunit folder, and had composer replace it via composer update. At that point, I'm able to run unit tests again as before. However this doesn't work as seamlessly on Windows 7. It's trickier.

My question is: Am I doing something wrong by tracking the files through github and then working on various operating systems? Would I avoid this error if I only kept track of composer.json and keep the contents of vendor/phpunit/phpunit directory untracked (and let the files stay with their specific OS)? Thanks, Adam.

Adam T
  • 151

1 Answers1

0

The purpose of Composer is that you just have to have an empty(!) vendor directory in your repo but track composer.json (requirements) and composer.lock (last tested specific versions) and run composer install after checkout on a new development machine.

(NB. composer install will install the specific versions according to the composer.lock file. composer update will install whatever latest version matches the requirements defined in the composer.json.)

Composer should then download the appropriate binary for your system and put it into the vendor/bin/ directory.

mbirth
  • 778