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

Микрофронтенды — это архитектурный подход, при котором большое фронтенд-приложение разбивается на несколько независимо разрабатываемых и деплоимых частей. Ключевой вопрос: как хост-приложение (shell) узнаёт о микрофронтендах и включает их в свою сборку или загружает во время работы.

Основные способы подключения

• Build-time интеграция — микрофронтенд публикуется как npm-пакет, хост импортирует его как обычный модуль. Всё попадает в один бандл.
• Runtime интеграция через Module Federation — хост и удалённые модули собираются отдельно, а во время выполнения обмениваются модулями через общий контейнер.
• Динамическая загрузка скриптов — хост подгружает JS-бандл микрофронтенда через тег script и монтирует его в DOM.
• Iframe — микрофронтенд изолирован в отдельном документе, общение через postMessage.

Пример с Module Federation

В конфигурации Webpack хост объявляет удалённые модули, а микрофронтенд — что он экспортирует.

// webpack.config.js хоста
new ModuleFederationPlugin({
  remotes: {
    products: 'products@http://localhost:3001/remoteEntry.js'
  }
});

// webpack.config.js микрофронтенда
new ModuleFederationPlugin({
  name: 'products',
  filename: 'remoteEntry.js',
  exposes: {
    './ProductList': './src/ProductList'
  }
});

// Использование в хосте
const ProductList = React.lazy(() => import('products/ProductList'));

Как это попадает в сборку

При build-time всё включается в один бандл на этапе компиляции. При runtime хост не содержит код микрофронтенда — он лишь ссылается на remoteEntry.js, который загружается в браузере. Это позволяет деплоить микрофронтенды независимо, без пересборки хоста.

Итог: build-time проще, но связывает релизы; runtime через Module Federation даёт независимость деплоя и подходит для крупных команд, тогда как iframe и script-теги применяют для изоляции или legacy-систем.