Архитектура фронтенда
Monorepo: срезать CI с мира до среза
Читать про hub-пакеты — не то же самое, что вырезать один из живого пайплайна. Возьми monorepo, где изменение в одну строку пересобирает всё, найди hub по графу, почини границы и ключ кэша и приведи CI с целого репозитория к срезу — с доказательством на каждом шаге.
Преврати ментальную модель юнита в воспроизводимый инженерный цикл: визуализируй граф зависимостей, измерь affected-набор и hit rate кэша, почини структурную причину (hub и границы) раньше косметических, подключи корректный кэш и подтверди падение CI цифрами до/после.
Возьми multi-package monorepo, где каждый PR пересобирает большую часть репозитория (свой или построй стартер на ~12-20 пакетов с одним hub @acme/utils), и приведи CI типичного PR с целого репозитория к маленькому affected-срезу — без покупки раннеров помощнее — доказывая каждый шаг измерениями.
- Таблица до/после: размер affected-набора (число проектов) и wall-clock CI для изменения в листе И для изменения в домене hub, измеренные на одном пайплайне — не оценочно.
- Граф зависимостей ясно показывает, что hub исчез после разбиения (перегенерирован, а не предположен), а зависимые бывшего hub перераспределены по узким листовым пакетам.
- Демонстрация, что правило границ отклоняет запрещённый восходящий импорт на линте, с упавшим логом CI.
- Демонстрация кэша: тёплый прогон неизменённого проекта попадает и восстанавливается заметно меньше чем за секунду, а намеренное изменение tsconfig корректно инвалидирует кэш (без false hit).
- Абзац-разбор, называющий для каждого рычага (разбить hub, выставить границы, починить ключ кэша), почему он встал выше покупки раннеров помощнее или разбиения на polyrepo.
- Добавь CI-гейт, печатающий размер affected-набора на каждом PR и роняющий (или предупреждающий), если одно изменение затрагивает больше заданной доли репозитория, — раннее предупреждение, что формируется новый hub.
- Внеси баг false hit: оставь общий конфиг вне входов кэша, покажи отдачу устаревшего артефакта, затем почини ключ и докажи, что то же изменение теперь инвалидирует корректно.
- Сравни Turborepo и Nx на одном репозитории для одной задачи: генерация графа, точность affected и время тёплого попадания, и опиши, где каждый сильнее.
- Добавь changesets (или аналог) для версионирования теперь-узких общих пакетов и сопоставь release-флоу с тем, во что обошлось бы то же изменение как отдельные polyrepo.
Это цикл, который ты запустишь на каждом медленном monorepo: сначала визуализируй граф, измерь affected-набор и hit rate, затем чини с верха лестницы — разбей hub и выстави границы раньше, чем трогать железо, и сделай ключ кэша корректным раньше, чем доверять hit rate. Защити граф правилом границ и гейтом размера affected и подтверди падение CI цифрами до/после на одном пайплайне. Сделав это однажды на маленьком репозитории, ты превращаешь продакшен-версию в мышечную память.