Vendors в git

[fixxxer]

ну я не знаю

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

 

[WMix]

@fixxxer монорепа это же круто, но это не значит что все в одной ветке, это только значит что одна система контроля

 

[fixxxer]

монорепа это же круто

Нет.

 

[AnrDaemon]

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

 

[grigori]

Docker Blog | Docker

Generative AI (GenAI) and the models behind it have already reshaped how developers write code and build applications. But a new class of artificial intelligence is emerging: agentic AI. Unlike GenAI, which focuses on content generation, agentic systems can plan, reason, and take actions across...

blog.docker.com

Последний тип.

> 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]

сборки бинарных зависимостей на одном jre, а запускать будем на другом;

Чем это отличается от образа с композером, который не нужен на проде?

 

[AnrDaemon]

Получается, что главный аргумент - у вас фронт в одной репе с php

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

Никак не вижу страдания от наличия в репе кода, который все-равно есть

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

 

[WMix]

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