Как контролировать модульность архитектуры фронтенд-приложения и предотвращать появление лишних зависимостей между модулями?

Модульность фронтенда — это не просто разбиение кода на папки, а система правил, которая определяет, кто и что может импортировать. Без контроля зависимостей проект быстро превращается в «спагетти», где изменение одного модуля ломает пять других.

Ключевые принципы

• Каждый модуль имеет публичный API (index.ts или barrel-файл) и скрытую реализацию.
• Зависимости направлены строго в одну сторону: например, features зависят от shared, но не наоборот.
• Циклические зависимости запрещены.
• Слои (app, pages, features, entities, shared) не могут импортировать друг друга вверх по иерархии.

Инструменты контроля

ESLint с плагинами no-restricted-imports, import/no-cycle и правилами Feature-Sliced Design позволяет описать архитектурные границы декларативно. dependency-cruiser строит граф зависимостей и валидирует его по правилам. TypeScript paths и barrel-файлы задают публичные точки входа модуля.

// .eslintrc.js
rules: {
  'no-restricted-imports': ['error', {
    patterns: [{
      group: ['@/features/*/*'],
      message: 'Импортируйте только через публичный API модуля'
    }]
  }],
  'import/no-cycle': 'error'
}

// dependency-cruiser config
forbidden: [{
  name: 'no-upward-imports',
  from: { path: '^src/shared' },
  to: { path: '^src/features' }
}]

Практика

В проекте заводят папку shared с утилитами и UI-китом, entities с бизнес-сущностями, features с пользовательскими сценариями. Каждый модуль экспортирует только то, что нужно снаружи, через index.ts. CI-пайплайн запускает линтер и dependency-cruiser, блокируя merge при нарушении границ.

Итог: контроль модульности через архитектурные правила и автоматические проверки в CI позволяет команде безопасно развивать проект, не превращая его в монолит из связанных файлов.