В экосистеме микрофронтендов механизм федерации модулей в Webpack стал ключевым способом разделения и повторного использования кода между независимыми приложениями. Базовая идея Module Federation заключалась в том, чтобы одно приложение во время выполнения могло загружать модули из другого, не пересобирая их заранее и не дублируя зависимости.
Вторая версия этой концепции развивает первоначальную модель, устраняя ограничения ранней реализации и добавляя более гибкую систему управления зависимостями, версионированием и динамическим подключением удалённых модулей. Основной фокус смещается с простой «публикации и потребления» на полноценную координацию модулей в распределённой среде исполнения.
В Module Federation 2.0 runtime становится более самостоятельным и структурированным. Если в первой версии значительная часть логики была завязана на конфигурацию сборки, то теперь появляется более явное разделение:
Runtime перестаёт быть просто обёрткой над webpack bootstrap и превращается в полноценный слой координации модулей. Это позволяет уменьшить связность между host и remote приложениями.
Особое внимание уделено тому, чтобы runtime мог обновляться и расширяться без пересборки всего графа зависимостей.
Одним из ключевых улучшений становится расширенная поддержка динамических remote-URL. В ранних реализациях список remote был статическим и задавался на этапе сборки. Теперь появляется возможность:
Это превращает federation в более адаптивную систему, где архитектура приложения может меняться в зависимости от условий выполнения.
Вместо жёстко заданной строки появляется слой разрешения:
const remotes = {
appA: () => import(getRemoteUrl("appA"))
};Такая модель позволяет внедрять multi-tenant архитектуры и runtime-конфигурацию микрофронтендов.
Система shared dependencies в Module Federation 2.0 переработана для более точного контроля версий и поведения singleton-модулей.
Основные изменения:
Shared scope теперь функционирует как централизованный реестр, в котором каждая зависимость проходит этап согласования перед использованием.
Особое значение имеет поведение singleton-зависимостей. Например, библиотеки состояния или UI-фреймворки могут быть гарантированно использованы в единственном экземпляре даже при наличии нескольких remotes.
shared: {
react: {
singleton: true,
requiredVersion: "^18.0.0"
}
}Теперь механизм способен не просто предотвращать дублирование, но и выбирать оптимальную версию в зависимости от графа потребления.
Одним из сложных аспектов микрофронтендов остаётся управление конфликтами версий. Module Federation 2.0 вводит более формализованный процесс negotiation:
Если раньше конфликт версий часто приводил к runtime-ошибкам или дублированию библиотек, то теперь система старается разрешить его до момента выполнения модуля.
Это особенно критично для библиотек с глобальным состоянием и side-effect зависимостями.
Вторая версия вводит концепцию manifest-файла как промежуточного слоя описания remote-контейнера.
Manifest содержит:
Такой подход позволяет отделить runtime-загрузку от webpack-конфигурации и использовать federation в окружениях, где сборка и исполнение разделены (edge runtime, serverless, CDN).
Manifest также упрощает предварительный анализ совместимости между host и remote без необходимости их загрузки.
Асинхронность становится базовой моделью взаимодействия между модулями. В Module Federation 2.0 любой remote трактуется как потенциально отложенный ресурс, который может:
Это приводит к более предсказуемой модели производительности, где каждый remote становится независимой единицей загрузки.
Добавляется более строгая работа с chunk boundaries, что уменьшает риск дублирования кода и лишних сетевых запросов.
В новых механизмах federation усиливается изоляция runtime-сред. Каждый remote может иметь собственный execution context, что снижает риск:
Runtime начинает отслеживать side-effect модули и помечать их для корректной загрузки в shared scope.
Это особенно важно для крупных систем, где десятки независимых команд поставляют свои части интерфейса.
Механизм exposes становится более гибким и поддерживает не только экспорт модулей, но и логическую группировку API.
Вместо плоской структуры экспорта появляется возможность:
exposes: {
"./ui": "./src/ui/index",
"./services": "./src/services/index"
}При этом runtime может оптимизировать загрузку, подгружая только необходимые части экспонированного интерфейса.
Вторая версия смещает модель с «host + remotes» к полноценному графу зависимостей, где каждый узел может:
Это приближает архитектуру к распределённой системе модулей, где границы приложений становятся условными.
Graph runtime строится постепенно, по мере загрузки приложения, и может изменяться в процессе исполнения.
При переходе с первой версии federation основной проблемой становится несовместимость runtime-ожиданий. Module Federation 2.0 решает это через:
Старые конфигурации могут работать без изменений, но не получают преимуществ новой модели до обновления runtime-части.
Особое внимание уделяется постепенной миграции крупных монорепозиториев, где невозможно одномоментно обновить все remote.
Новая версия усиливает возможности предзагрузки модулей. Runtime может:
Это снижает задержки при переходах между микрофронтендами и делает federation более «плавной» в пользовательском восприятии.
Предиктивная загрузка становится частью архитектуры, а не внешней оптимизацией.
Module Federation 2.0 усиливает роль плагинов внутри runtime. Появляется возможность вмешиваться в:
Это превращает federation в расширяемую платформу, а не фиксированный механизм webpack.
Плагины могут реализовывать:
При работе с удалёнными модулями возрастает значение изоляции и контроля доверия. Вторая версия вводит более строгую модель:
Это снижает риски выполнения неподконтрольного кода и делает federation пригодным для более строгих enterprise-сценариев.