Архитектура фронтенд-монорепозитория на Nx: строгие границы и изоляция библиотек
Как не превратить корпоративный монорепозиторий в спагетти с помощью ESLint module-boundaries и Feature-Sliced подхода.
1. Ловушки масштабирования: когда монорепозиторий становится обузой
Монорепозиторий обещает единый источник правды, переиспользование компонентов и атомарные коммиты. Однако без жесткой архитектурной дисциплины он быстро деградирует: разработчики начинают хаотично импортировать утилиты из чужих фич, возникают циклические связи, а время сборки в CI улетает в бесконечность.
2. Тегирование библиотек и правила module-boundaries
Ключевой инструмент защиты архитектуры в Nx — плагин @nx/enforce-module-boundaries. Каждому проекту присваиваются теги двух измерений: тип слоя (type:app, type:feature, type:ui, type:util) и доменная область (scope:shared, scope:admin, scope:billing).
Правила линтинга гарантируют, что UI-компоненты не могут импортировать сервисы фичей, а домен биллинга не имеет доступа к коду админ-панели.
3. Граф affected и локальный вычислительный кэш
Благодаря графу зависимостей Nx пересобирает и тестирует только те пакеты, которые затронуты изменениями в конкретной ветке. В сочетании с распределённым кэшем это сокращает время прохождения CI в 3–5 раз даже на масштабных кодовых базах.