使用Composer时，如何在另一个存储库中处理存储库？

Question

I have a project and I use Git for doing version control in this project. Within this project I have to add a few libraries as dependencies (more specifically PHPUnit and Guzzle). The requirements say that these libraries have to live in a folder of my project and I have to use composer to install/update them.

So I did that and my directory structure looks something like this:

project
|----- .git
|----- libs
        |---- guzzle
                |---- .git
        |---- phpunit
                |---- .git

So the guzzle and phpunit folders both have a separate .git folder. This is because, as far as I can tell, composer makes a clone of the master branch from github in order to retrieve the source code of these libraries.

So I did a commit+push on a remote repository. However, when someone else pulls from that repository, the files contained in the libs/guzzle and libs/phunit folders do not appear in that person's working directory.

I'm thinking this is because of the 2 .git folders.

How can I fix this ? I tried searching the documentation of composer for a way to specify in composer.json to get ONLY the last snapshot so to speak. But I couldn't find anything.

I also thought about deleting the .git directories, but won't that break everything if I try to do a composer update in a few months ?

Did anyone have this sort of problem in the past ? How did you solve it ?

Answer 1

I have some comments and explanations.

First, your usage of Composer created git clone artefacts. While this isn't completely bad, it should be avoided because cloning a repo of an active project usually is a lot more data than installing a released version.

Try to use --prefer-dist if you can. This will download ZIP files of the version, not clone from Github. Note that this option is the default for stable versions, which brings me to the next point...

Do use stable versions. Do not use dev-master versions if you can avoid it. You mentioned using PHPUnit and Guzzle. Both are released in stable versions that you can use. Do it. There is no benefit with these two libraries to use unstable development versions, unless you absolutely need a feature. The problem with using an unstable version might not be showing right away. But think about what would happen half a year from now. Somebody updates your dependencies pointing to dev-master, which now points to whatever happened since then. PHPUnit or Guzzle might have had a new major release with incompatible changes. And now your project breaks unnecessarily.

Another thing is the requirement to put external libraries in defined folders. It is doable, but it shouldn't really be done. Composer does work with any folder, but my usual reaction to seeing a composer.json in the top level directory is to expect getting a vendor folder containing the autoload.php. Changing this needs a little bit more of explanation to a new developer who might also expect Composer to work as default as possible. Because there is no reason to put Composer-managed dependencies anywhere, they are best put where everyone would expect them. Don't change the vendor folder if you don't have to.

And the last point is: Do commit your composer.lock, but don't commit the vendor folder. This is because the vendor folder might contain traces of the source control systems used by the external libraries, and these might confuse your projects source control. The correct workflow is to commit the composer.lock, and everybody checking out your project has to run composer install to grab these dependencies from the internet. This also applies to deployment scripts that do the checkout.