Composer — the right way

У нас давеча сложилась очень интересная и горячая дискуссия с коллегами по поводу использования Composer-а в проектах, над которыми мы работаем. Очень бы хотелось услышать мнение «широкой общественности» по этому вопросу.

Камнем преткновения стал очень простой вопрос:

Стоит ли хранить содержимое папки vendor в наших репозиториях?

Как Вы, в общем наверняка уже догадались, мнения разделились:

ДА

Это часть нашего приложения, за которое мы несем ответственность и все зависимоасти должны храниться в одном месте. В данном случае имеетс в виду, что без сторонних библиотек наш код теряет функциональность.

Контр-аргумент: в таком случае, нам надо еще завести в свой репозиторий используемые пакеты уровня операционной системы (apt-get, например). Ведь при использовании аналогичного инструмента в Java — Maven, например, никто же не хранит сторонние зависимости, а только описание оных. Сюда же можно отнести npm, pip и прочие.

НЕТ

Это 3-rd party библиотеки, которые мы просто используем. Желаемого эффекта «неизменности» можно достичь жесткой фиксацией версии библиотеки в composer.json.

Контр-аргумент: отсутствие контроля над разработкой стороннего кода. В случае закрытия или «плохого кода» в проекте вендора, мы теряем функциональность.

Для полноты картины, пройдите, пожалуйста, небольшой опрос.

Ссылки:

• Composer — getcomposer.org
• Apache Maven — ru.wikipedia.org/wiki/Apache_Maven

UPDATE 1
В качестве зависимостей в данном случае имеются в виду официальные SDK для сторонних API, например, или инструменты автоматизации. Т.е. данные пакеты не могут исчезнуть за 1 день.

UPDATE 2
Обсуждение подразумевает хранение вендорского кода ни на прокси для packagist, ни в отдельных форках, а прямо в репозитории с проектом.

UPDATE 3
Под проектом подразумевается некое web-приложение или сервис, но не библиотека, разрабатываемая компанией.

UPDATE 4
В проекте есть и активно используется build для сборки js/css файлов. Это важно, потому что в этот процесс (по мнению автора) должна быть включена сборка php зависимостей.

UPDATE 5
Вышеупомянутые build-ы запускаются на тестовом окружении (или специальном build-сервере) и выкатываются на боевые сервера уже в готовом виде. Это значит что ситуация с разными версиями пакетов между test/stage/live в принципе не возможна.

UPDATE 6 & FINAL
Спасибо всем большое за дискуссию, ссылки и мнения. Эффект от статьи получился именно такой, как того задумал автор.