Vendors в git

[fixxxer]

ну я не знаю

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

 

[WMix]

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

 

[fixxxer]

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

Нет.

 

[AnrDaemon]

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

 

[grigori]

Docker Blog | Docker

The MCP protocol is almost one year old and during that time, developers have built thousands of new MCP servers. Thinking back to MCP demos from six months ago, most developers were using one or two local MCP servers, each contributing just a handful of tools. Six months later and we have...

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 и другое попадут в репу.
прям буквально как ты хочешь.