'решено' и 'гигантской монорепой' как-то проивоествественно вместе смотрятся. имхо, монорепа - это безоговорочный пиздец, а все плюсы монорепы - это лишь недоработки ci/cd и тестирования, а вовсе не плюсы монорепы.

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

Можно вводить новые фичи и без ломания API

Я очень понимаю монорепу, когда у тебя десятки компонент шарятся между разными проектами. Чтобы библиотеку поправил - и сразу же увидел, что теперь надо использование подправить.
Я думаю этот подход имеет свои ограничения, гугл вон в производительность гита уперся, но в некоторых кейсах единый репозиторий - очень даже удобное решение. Когда команда, которая работает с кодовой базой - человек 30-50 скажем.

Я думаю, что монорепа следствие ущербности инструментов для работы с несколькими репами. Мы всё ещё находимся в эпоху RCS. Следующая революция систем контроля версий случится именно тут

Не всегда это возможно без костылей. Вот был у тебя пользователь, а теперь надо поддерживать несколько профилей.
Вот была у меня библиотека для авторизации в машине по блутусу, а теперь машины имеют новые девайсы и там другие стадии авторизации появились. Вот чтобы их поддержать - я должен изменить колбеки, добавить дополнительные методы и т.п.
А использующие клиенты - должны их реализовать.

Монорепа позволяет забыть про ABI в принципе. И это хороший аргумент в её пользу, как по мне.

пробовал. это проблема процессов и управления, и не стоит её решать за счёт реп и кода.
в разрезе бека, это решается раскаткой опеределённых версий сервисов для потребителей завязанных на определённую версию. для общих точек входа - версионированием апи, которое разруливается на гейтвее. а вот самый большой косяк в этой истории - "я нихачу обновлятся, но хочу доработку в старую версию" от проудктовых чуваков - это ата-та и разговор с архитектором на тему "какого х", в беклог задачу на обновление, если нужно срочно берите и городите мешаппер (нефиг свои косяки и тормоза распространять на другие отделы и системы), который будет делать транмформацию до нужной кондиции или обогащения с дургого апи. и попутно ведём ADR каким-либо образом, чтобы не запутаться

системы и контура предприятия должны быть изолированны по максимуму, чтобы потом вся организация не сыграла в домино, от очередных чуваков, которые не могут осилисть обновление и разруливание своих зависомстей от других систем. монорепа очень способствует неявной куче мале.
а про шаринг комопнентов это вопрос кульутруы и архитектоуры - для либ, обмазываемся innersoruce подходом, для сервисов версионированием, документацией и в идеале стремиимся к service mesh. а монорепа - это костыль как ни крути, имхо. не стоит пытаться адаптировать чьё-то 'исторически сложилось'. "вот у гугла так..." - ты гугл что ли, а?

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

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

Когда команды, которые пользуются кодом друг друга не то что не знакомы, а находятся в совершенно разных организационных структурах

тем более, им нафиг не нужна одна репа. это создаёт сильную зависимость между разными отделами и продукатми, которой быть по идее вобще не должно. а теперь пресдтавь что какой-то одной команде потребовалось изменение в ci/cd пайплайне монорепы, например они себе хотят добавить стадию ФТ. да там просто жопы у всех сгорят это согласовывать

не нужно ничего согласовывать. нормальный CI у монорепы запускает только часть задач, связанных с изменениями кода и описываться конфиге подпапки проекта. А что до сильных зависимостей – заебёшься кор библиотеки разрабатывать со "слабыми зависимостями" с зоопарком версий и постоянными завтраками

не заебёшься, если огранизационно процессные проблемы решать на уровне процессов, а технические на техническом. разработку надо контролировать и следить за ней, чтобы они как раз друг друга не поубивали. есть такой термин IT governance - контроль и понимание, что у тебя проиходит в органзации, какая стратегия и подходы, чтобы был контроль команд и разработки и они не делали хуйни. а ты предлагаешь хлюпающее болото, под названием монорепа, чтобы разрабы как-то магическом образом сами разобрались, чисто из-за того, что завязанны на одну кучу кода.

у них тогда хотя бы будут incetives разбираться в этом а не бугуртить на бюрократию этих самых governors

Я предлагаю фиксить использование тогда, когда ты рефакторишь. А не сочинять отмазки, что пользователям моего апи надо выделять рабочее время, чтобы 5 человек 5 раз разбирались почему что-то сломалось. Или что все внутренние бизнес утилиты надо писать как мейнстрим библиотеки, чтобы апи было вечным. Хотя и там ломают.

время постить #котиков

Как тебе такое, Илон Маск?

А как такое?

Фу, micro usb, древнее говно