Vendors в git

fixxxer

К.О.
Партнер клуба
ну я не знаю

мне vendors в репе видится куда большим злом, чем хоть сколь угодно черезжопный способ делать composer install в докере :)
 

WMix

герр M:)ller
Партнер клуба
@fixxxer монорепа это же круто, но это не значит что все в одной ветке, это только значит что одна система контроля
 

AnrDaemon

Продвинутый новичок
Вы ещё гориллу, дерево и все джунгли в репу запихните.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума

Последний тип.
> include all our build dependencies
как я написал выше - форма шизофрении, возомнили себя java-разработчиками, которым нужен отдельный build, сборки бинарных зависимостей на одном jre, а запускать будем на другом;
спасибо, я на php как-нибудь обойдусь и без компиляции, и без сборки: нет, господа, composer install - это не сборка, это артефакты
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
@grigori а фронтэндеры ваши держат в гите скомпиленные из тайпскрипта или чего другого js-ки? Скомпиленные css-ки? По твоим аргументам - должны)

Я сейчас, к сожалению на проекте где все держат там. и вендоры и скомпиленное. Как раз, чтобы все было готовое и не надо было каждому девелоперу компилить и инсталл делать. Но диффки смотреть некоторые - ужас. А про сложные мержи и говорить нечего.
фронт в отдельной репе, его делает отдельный человек, я даже специально выше написал, что вопрос только про php
у меня rest api middleware
Гит придумали и сделали не для удобного деплоя, а для хранения и удобного манипулирования собственных сорцов.
это ты прочел где-то или только что придумал? :)
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Я вообще не понимаю, как держать vendors в репе. А что делать с собственными зависимостями (вот написали либу и используем тут и там)? Копипастить везде, и когда баг поправили обновлять везде ручками?
не понимаю, чем обновление внутренней либы отличается от обновления чужой - это артефакт, если версия меняется, и надо обновлять - надо проверить совместимость со всеми продуктами,
интеграционные тесты и регрессии, которые вылезают - проблема на несколько порядков более трудоемкая, чем просто обновление любым способом

А с фронтендом что? Держать собранные css и js тоже в репе?
Получается, что главный аргумент - у вас фронт в одной репе с php, его все-равно надо компилить, и раз уж не повезло, то другие варианты вы считаете злом.

В любом случае в любом вменяемом проекте так или иначе будет система сборки, без этого же вообще невозможно. Чем там вообще мешает composer install?
Нету у нас сборки в php. Ее вообще никогда не бывает. Есть копирование неизменяемых артефактов в папку. Это ты на ноде много пишешь.
Есть деплой, есть тесты, а сборка бывает только архива для передачи на деплой, но это вообще другая тема.

Я при старте контейнера вызываю проверку vendors и установку, если папка пустая. Но непонятно зачем.

С разработкой вообще никаких проблем быть не должно: если все не через задницу, разработчик запустил docker-compose up и все само сделалось.
Так будет в обоих случаях.

Ну или я понимаю, что у кого-то там исторически сложилось - монорепы на 100 терабайт и прочий идиотизм, но то, что кто-то усложнил себе жизнь и страдает, не повод страдать так же :)
Никак не вижу страдания от наличия в репе кода, который все-равно есть в папке и при разработке, и на сервере. Разница в одной записи в .gitignore и в скорости разворачивания. Composer install дольше.
 

fixxxer

К.О.
Партнер клуба
Нету у нас сборки в php. Ее вообще никогда не бывает.
Ну почему, генерация автолоадера это как раз сборка.
А еще бывает кодогенерация (нечасто, конечно, но - бывает).
Я предпочитаю не держать в репе ничего, что генерится.

Это ты на ноде много пишешь.
Ты так говоришь, как будто это что-то плохое.
Я вот еще и на джаве/котлине немного пишу. :)
Ну и да, я отношусь к php-коду как к приложению, а не как к "скриптикам, которые заливают по ftp". Это не значит, что я буду докер-контейнер с php-кодом, совмещенный с php-бинарями, собирать. Но я и для typescript этого не делаю. Data volume достаточно.

Получается, что главный аргумент - у вас фронт в одной репе с php
Где-то (в легаси) так, где-то (в новом) не так. Один фиг, не вижу принципиальной разницы между composer install и npm install.

Никак не вижу страдания от наличия в репе кода, который все-равно есть в папке и при разработке, и на сервере
Может тогда и бинарь php в репу положить? А чо, тоже "артефакт".

Как кодревьюить ветку, в которую залили либу? Ну, понимаю, что можно ревьюить отдельные коммиты. Ок. Как убедиться, что там в vendor/ ничего не поправили ручками?

Composer install дольше.
Нормальные CI умеют кэширование: если composer.lock не менялся, то разницы по времени вообще никакой.
 
Последнее редактирование:

AnrDaemon

Продвинутый новичок
Получается, что главный аргумент - у вас фронт в одной репе с php
Кто тебе сказал такую глупость-то? Из чего вообще такой вывод сделан?
У фронта проблема ровно та же, что и у бэка - зависимости, внешние библиотеки - их тоже в репо хранить?
Зачем хранить в рабочем репо то, что можно не хранить? То, к чему ты никогда не прикасаешься во время разработки, и что только мешает при обновлениях?

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

WMix

герр M:)ller
Партнер клуба
а вот если собрать все вместе с докером и за-push-ить то в итоге и vendor, и node_modules, и необходимые jar, и с-transpile-рованные js-файлы, и скомпеленные less/scss и сгенерированный twig/doctrine - chache и другое попадут в репу.
прям буквально как ты хочешь.
 
Последнее редактирование:
Сверху