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.

1 Answer 1

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.

2
  • I am just confused since it all works fine, then I push tests to the remote repository. For some reason the vendor folder itself gets LOTS of modifications, that (I am guessing) upon a git pull from other machine the compatibility and path-finding of the executable vendor/bin/php go out of whack.
    – Adam T
    Jul 14, 2015 at 15:27
  • I have done the composer install after the checkout on the new development machine. What I'm not understanding is just 'how' git "thinks" all these files have been modified (from the vendor folder) when I didn't touch em. Of course doing a pull down of files specific to a winders machine might confuse a different machine altogether, which is why the thought of simply "not tracking" these files came to mind. Track composer.json, but do not bother with tracking the files that composer may pull down.
    – Adam T
    Jul 14, 2015 at 15:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.