Нет.монорепа это же круто
> include all our build dependencies![]()
Intro Guide to Dockerfile Best Practices - Docker Blog
Learn from Docker experts to simplify and advance your app development and management with Docker. Stay up to date on Docker events and new version announcements!blog.docker.com
Последний тип.
фронт в отдельной репе, его делает отдельный человек, я даже специально выше написал, что вопрос только про php@grigori а фронтэндеры ваши держат в гите скомпиленные из тайпскрипта или чего другого js-ки? Скомпиленные css-ки? По твоим аргументам - должны)
Я сейчас, к сожалению на проекте где все держат там. и вендоры и скомпиленное. Как раз, чтобы все было готовое и не надо было каждому девелоперу компилить и инсталл делать. Но диффки смотреть некоторые - ужас. А про сложные мержи и говорить нечего.
это ты прочел где-то или только что придумал?Гит придумали и сделали не для удобного деплоя, а для хранения и удобного манипулирования собственных сорцов.
не понимаю, чем обновление внутренней либы отличается от обновления чужой - это артефакт, если версия меняется, и надо обновлять - надо проверить совместимость со всеми продуктами,Я вообще не понимаю, как держать vendors в репе. А что делать с собственными зависимостями (вот написали либу и используем тут и там)? Копипастить везде, и когда баг поправили обновлять везде ручками?
Получается, что главный аргумент - у вас фронт в одной репе с php, его все-равно надо компилить, и раз уж не повезло, то другие варианты вы считаете злом.А с фронтендом что? Держать собранные css и js тоже в репе?
Нету у нас сборки в php. Ее вообще никогда не бывает. Есть копирование неизменяемых артефактов в папку. Это ты на ноде много пишешь.В любом случае в любом вменяемом проекте так или иначе будет система сборки, без этого же вообще невозможно. Чем там вообще мешает composer install?
Так будет в обоих случаях.С разработкой вообще никаких проблем быть не должно: если все не через задницу, разработчик запустил docker-compose up и все само сделалось.
Никак не вижу страдания от наличия в репе кода, который все-равно есть в папке и при разработке, и на сервере. Разница в одной записи в .gitignore и в скорости разворачивания. Composer install дольше.Ну или я понимаю, что у кого-то там исторически сложилось - монорепы на 100 терабайт и прочий идиотизм, но то, что кто-то усложнил себе жизнь и страдает, не повод страдать так же![]()
Ну почему, генерация автолоадера это как раз сборка.Нету у нас сборки в php. Ее вообще никогда не бывает.
Ты так говоришь, как будто это что-то плохое.Это ты на ноде много пишешь.
Где-то (в легаси) так, где-то (в новом) не так. Один фиг, не вижу принципиальной разницы между composer install и npm install.Получается, что главный аргумент - у вас фронт в одной репе с php
Может тогда и бинарь php в репу положить? А чо, тоже "артефакт".Никак не вижу страдания от наличия в репе кода, который все-равно есть в папке и при разработке, и на сервере
Нормальные CI умеют кэширование: если composer.lock не менялся, то разницы по времени вообще никакой.Composer install дольше.
Чем это отличается от образа с композером, который не нужен на проде?сборки бинарных зависимостей на одном jre, а запускать будем на другом;
Кто тебе сказал такую глупость-то? Из чего вообще такой вывод сделан?Получается, что главный аргумент - у вас фронт в одной репе с php
Ты понимаешь, что твой аргумент тривиально доводится до абсурда?Никак не вижу страдания от наличия в репе кода, который все-равно есть