Как обрабатывать репозиторий внутри другого репозитория при использовании Composer?

У меня есть проект, и я использую Git для управления версиями в этом проекте. В рамках этого проекта я должен добавить несколько библиотек в качестве зависимостей (точнее, PHPUnit и Guzzle). Требования говорят, что эти библиотеки должны жить в папке моего проекта, и я должен использовать композитор для их установки и обновления.

Поэтому я сделал это, и моя структура каталогов выглядит примерно так:

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

Таким phpunit папки phpunit и phpunit имеют отдельную папку .git . Это потому, что, насколько я могу судить, композитор делает клон ведущей ветви из github, чтобы получить исходный код этих библиотек.

Поэтому я сделал фиксацию + нажатие на удаленный репозиторий. Однако, когда кто-то вытаскивает из этого репозитория, файлы, содержащиеся в папках libs/phunit и libs/phunit , не отображаются в рабочем каталоге этого человека.

Я думаю, что это из-за двух .git папок.

Как я могу это исправить ? Я попытался найти документацию композитора, чтобы указать в composer.json чтобы получить ТОЛЬКО последний снимок, так сказать. Но я ничего не мог найти.

Я также думал об удалении каталогов .git , но разве это не сломает все, если я попытаюсь сделать composer update для composer update через несколько месяцев?

У кого-нибудь была такая проблема в прошлом? Как вы его решили?

У меня есть комментарии и объяснения.

Во-первых, ваше использование Composer создало артефакты git clone . Хотя это не совсем плохо, его следует избегать, поскольку клонирование репо активного проекта обычно намного больше данных, чем установка выпущенной версии.

Попытайтесь использовать --prefer-dist если сможете. Это будет загружать ZIP-файлы версии, а не клонировать из Github. Обратите внимание, что эта опция является стандартным для стабильных версий, что приводит меня к следующему пункту …

Используйте стабильные версии. Не используйте dev-master версии, если вы можете избежать этого. Вы упомянули использование PHPUnit и Guzzle. Оба выпускаются в стабильных версиях, которые вы можете использовать. Сделай это. Для этих двух библиотек нет пользы использовать нестабильные версии разработки, если только вам не нужна функция. Проблема с использованием нестабильной версии может не отображаться сразу. Но подумайте о том, что произойдет через полгода. Кто-то обновляет ваши зависимости, указывая на dev-master , который теперь указывает на то, что произошло с тех пор. PHPUnit или Guzzle, возможно, имели новый основной выпуск с несовместимыми изменениями. И теперь ваш проект ломается без необходимости.

Другое дело, это требование размещения внешних библиотек в определенных папках. Это выполнимо, но это не должно быть сделано. Composer действительно работает с любой папкой, но моя обычная реакция на то, чтобы увидеть composer.json в каталоге верхнего уровня, должна ожидать получить папку vendor содержащую autoload.php . Изменение этого требует немного больше объяснений новому разработчику, который также может ожидать, что Composer будет работать как можно более по умолчанию. Потому что нет никаких оснований полагаться на зависимости, управляемые с помощью Composer, везде лучше всего их ожидать. Не изменяйте папку vendor если вам это не нужно.

И последний момент: Do commit your composer.lock , но не vendor папку vendor . Это связано с тем, что папка поставщика может содержать следы исходных систем управления, используемых внешними библиотеками, и это может смутить управление исходными вашими проектами. Правильный рабочий процесс состоит в том, чтобы зафиксировать composer.lock , И каждый, кто проверяет ваш проект, должен выполнить composer install чтобы захватить эти зависимости из Интернета. Это также относится к сценариям развертывания, выполняющим проверку.

Очевидно, что я пытаюсь сделать, это плохая идея, как упоминалось здесь . Мне нужно будет найти другой способ установки / использования этих библиотек.