После долгой работы с nrwl уже начинаю приходить к такому же выводу)

Мне кажется проблема в том что монорепы окупаются для кодовой базы > 1M или еще больше

бедные ваши IDE)

Я в рамках одного приложения иногда выносил объемные модули в либы не публичные nrwl для удобства

Возможно и написано. Я открыл две наиболее свежие книги по ангуляру и там про это не было ни слова.

Хотя вроде как коллектив авторов там довольно серьезный.

хехе, книги

Как мне кажется проблемы с монорепозиториями из-за неправильного подхода к разработке. В любом случае, есть множество проблем как для монорепозитория и полирепозитория.

К тому же тут стоит учитывать, что большие проекты все же имеют немного другие особенности разработки, нежели маленькие. Какие-то маленькие вещи они, конечно, могут доставлять практически мгновенно (дни-недели). Но что-то более крупное обычно укладывается в огромную инженерную работу, которая начинается с самого основного — проектирования.

Проектирование изменений может занимать не часы, и не дни, а месяца. 3 месяца вполне нормально для крупных компаний, чтобы запланировать ряд изменений. Причем все работы должны быть проделаны в определенный период времени, и по окончанию собираться все воедино.

И вот, когда определились с тем, что разработка и доставка фичи может занимать продолжительное время, от сюда можно сделать вывод, что не особо то и важно что у тебя — монореп или полиреп.

Теперь вернемся к реализации. Для решения вопросов версионности, единственный способ его решить — фиксация контрактов для взаимодействия между модулями и автоматический рефакторинг. А значит, опять таки, необходим серьезный инженерный подход. Должен ли использоваться подход только для монорепозиториев? Я думаю, что без разницы.

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

Тогда в чем же преимущество, если все равнозначно? Здесь как раз и вступает в силу мощь монорепы. Она дает на более поздних этапах независимо от всех остальных возможность вносить новые изменения, которые исправляют неправильное поведение функционала или добавляют незначительные фичи.

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

Сорян за много текста)

Фиксация контракта не работает для больших проектов из за Закона Хайрама http://www.hyrumslaw.com

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

With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.

Тут проблема не в проектировании

With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.

Мы ведь говорим про то, как ведут разработку в Google, Microsoft?

Не важно. Закон приминим ко всем крупным проектам, с большим кол-вом консьюмеров API

К слову, знаешь почему Apple начала сильно факапиться?

Или почему мы не видим серьезных изменениях в ОС на протяжении всего года?

А какже подстановка и обратная совместимость? Тоже неработают? Где медиана когда закон хайрама начинает работать?

Неа, шарь знание 🙂

Ты весь текст прочитал по ссылке? 🙂

Конкретного графика увы нет. Но могу подвердить что он работает.