Можно ли сохранять в git папку vendor после composer update?

Question

[Алексей Сумин]

При использовании менеджера пакетов composer, все необходимые для проекта пакеты сохраняются в папке vendor, при этом общепринятая практика такая, что эту папку добавлять в git нельзя, вместо этого каждый разработчик после git clone должен делать composer install и периодически composer update.
Мне такой подход не очень нравится по следующим причинам:

1. Если одни разработчик обновил библиотеки, другие должны как то об этом узнать, чтобы обновится у себя
   
2. Список библиотек и версии обновляются не очень часто, а при каждом релизе, приходится выкачивать одни и те же либы
   
3. В проекте могут быть заняты люди, которые не умеют (или не могут в данный момент) работать с консолью: верстальщики, технические писатели, ревьюер кода (безопасности), сюда же и вопрос оплаты специалиста, которые умеет всё
   
4. Нет возможности просто и быстро передать кому-то код, просто расшарив ссылку на гит
   
   

Вопрос в том, можно ли сохранять папку vendor в git, насколько это противоречит принятому стилю и какие могут быть проблемы с этим (сейчас самый жирный минус от такого подхода вижу в распухании репозитория) ? Использует ли кто-нибудь такую практику в своих проектах ?

Comments

[Алексей Сумин]

Александр А: это не всегда вопрос умения, код можно отдавать на аудит сторонней организации (или представителю заказчика), у которой полно таких проектов. Плюс бывает такая ситуация: ты не дома и не на работе, с собой есть только планшет или телефон, и вдруг захотелось проверить какую то мысль, открываешь github или bitbucket посмотреть исходники - а вендоров там нет...

[Дмитрий Вапельник]

Алексей Сумин: по поводу того, что вендоров нет: вендоры есть на гитхабе - заходим на packagist, ищем там нужний пакет, переходим на гитхаб и смотрим вендора. это не есть проблема

Answer 1

[index0h]

Если одни разработчик обновил библиотеки, другие должны как то об этом узнать, чтобы обновится у себя

Если другие разработчики делают git pull и не обращают внимания на изменения - это их проблемы. Хорошим тоном является уведомление от автора правок в composer.json, что остальным стоит его обновить.

Список библиотек и версии обновляются не очень часто, а при каждом релизе, приходится выкачивать одни и те же либы

Вообще говоря композер умеет в кэш и одни и те же версии либ тянутся с кэша.

В проекте могут быть заняты люди, которые не умеют (или не могут в данный момент) работать с консолью: верстальщики, технические писатели, ревьюер кода (безопасности), сюда же и вопрос оплаты специалиста, которые умеет всё

Если нужно именно поднять окружение с проектом - настройте vagrant и пропишите в README как им пользоваться конкретно для вашего проекта.
Что касается людей:
* верстальщики - vagrant
* технические писатели - я конечно не в курсе вашего проекта, но я бы доступ даже к репозиторию не дал, максимум - завел отдельный репозиторий для них.
* ревьюер кода (безопасности) - ревьюер, который не может в composer / консоль?? Шутка не удачная.
* сюда же и вопрос оплаты специалиста - лолшто? Это вообще не связано с окружением вашего проекта, ну вот ни капли.

Нет возможности просто и быстро передать кому-то код, просто расшарив ссылку на гит

Если у вас проект НЕ opensource - то такого делать в принципе нельзя. Доступ к репозиторию должны иметь специалисты, которые работают с кодом этого проекта и ни кто другой, а composer тут вот ни капли ни при чем!

Вопрос в том, можно ли сохранять папку vendor в git

НЕТ! Вы придумали НЕ существующую проблему и пытаетесь героически ее решить, только от этого решения будет еще хуже.

насколько это противоречит принятому стилю

на полностью

какие могут быть проблемы с этим (сейчас самый жирный минус от такого подхода вижу в распухании репозитория) ?

1. Вы становитесь вендором кода, который взяли где-то, как следствие вы следите за его обновлением, у изначального вендора и вы проводите аналогичные правки в своем проекте. Если так не делать - баги, найденные в этой зависимости сами себя не пофиксят и этот код будет быстро устаревать.
2. В код зависимости появляется соблаз провести собственные наработки - это то, что делать нельзя, иначе процесс обновления будет сложнее на порядки.
3. Ваш репозиторий разбухнет.
4. Композер вашу зависимость придется явно прописать иначе автолоад может ее не подтянуть.

Использует ли кто-нибудь такую практику в своих проектах ?

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

Comments

[Алексей Сумин]

спасибо за развернутый ответ

Answer 2

[aol-nnov]

> другие должны как то об этом узнать, чтобы обновится у себя
ну, ты же гитом пользуешься, да? прям пользуешься-пользуешься?
git fetch origin
git diff --name-only <yourbranch>..origin/<yourbranch> -- composer.json или как он там

Comments

[Алексей Сумин]

После каждого фетча проверять сравнивать composer.json ?

[aol-nnov]

Алексей Сумин: а тебе бы на печи лежать?
не проверяй после фетча - сразу запускай composer update. можно это в хук локального репа положить вообще.

[Алексей Сумин]

aol-nnov: причем тут печь, представьте, что у вас работает по найму программист, на ставке. 8 часовой рабочий день: из них он 6 часов пишет код и создаёт добавленную стоимость вашему продукту, а 2 часа настраивает "правильную" IDE, мониторит файлик comoser.json в каждом из N проектов находящихся в работе и т.д., зачем увеличивать непроизводственные расходы (во всех отраслях наоборот с этим борются) ?

[aol-nnov]

Алексей Сумин: каждый день чтоль ide-то настраивает? нормальный программист, который действительно "создает добавленную стоимость вашему продукту" всю рутину давно автоматизировал и пишет код, не отвлекаясь.

[aol-nnov]

Алексей Сумин: гит тоже выкинь за увеличение непроизводственных расходов. фетчить же надо, оужас, а не код писать! и ide выкинь - пиши в блокноте. через неделю поговорим о расходах снова :)

[Алексей Сумин]

aol-nnov: "всю рутину давно автоматизировал и пишет код, не отвлекаясь. " и как это соотносится с ручной проверкой composer.json ?

[aol-nnov]

Алексей Сумин:
> как это соотносится с ручной проверкой composer.json
где я писал про именно ручную проверку? если не хватает фантазии, куда мой совет применить, жаль.

Answer 3

[Aset]

vendor лучше не загружать в гит. Зачем собой тащить не сколько mb.

1. Он же разработчик пусть смотрит на коммит и composer.json
2. Не всегда так. Например я один раз поставил и забыл, остальные разработки через гит.
3. Git и Composer это стандарт в области веб-разработки, желательно его должны знать.
4. Делай на тестовым сервере vps.

Убери папку vendor из gitignore. Это очень плохая практика.

Comments

[Алексей Сумин]

"Убери папку vendor из gitignore. " а можно поподробнее, чем это плохо и как тогда избежать попадания vendor в git ?

[Станислав Почепко]

Про убрать из gitignore - тоже не понял. Расскажи.

[Aset]

Алексей Сумин: Вот например на фреймворке ларавел https://github.com/laravel/laravel/blob/master/.gi... убери /vendor

Answer 4

[Григорий Есин]

Можно, но смысла нет.
Вместо этого в гит мы кладём composer.lock и повесили гит-хук, который делает composer install при merge и checkout.
После этого проблему как рукой сняло.

Comments

[ismt]

А вдруг packagist будет недоступен, что, vendor руками собирать ? Или способы работы packagist изменились, или формат файла composer.json ?
Это конечно маловероятный вариант, но года за 3 многое может измениться. А так затянул гит, и оно работает, кстати внутри папки vendor валяются .gitignore, возможно это намек что папку vendor заливать всетаки можно

[Григорий Есин]

composer кеширует скаченные пакеты.
Во всяком случае, у нас за полтора года ещё не возникало проблем.
Если сильно волнует, то есть satis и, кроме того, можно поднять собственный packagist.