Знакомы ли с module federation

Что проверяют

Понимаете ли вы, как собрать фронтенд из частей, которые разные команды деплоят независимо, и какой ценой это даётся. Следом обычно спрашивают, как делятся общие зависимости вроде React и что будет, если удалённый модуль не загрузился.

Как отвечать

Если работали, коротко опишите проект, а потом механику. Если нет, скажите честно и покажите, что понимаете принцип: это ценится больше заученного «использовал в своих проектах».

Module Federation появилась в Webpack 5 как ModuleFederationPlugin. Суть в загрузке кода другого приложения во время выполнения, без пересборки хоста:

• remote: приложение, которое отдаёт модули через exposes и публикует входной файл, обычно remoteEntry.js;
• host: приложение, которое подключает remote через remotes и загружает его модули динамическим import();
• shared: общие зависимости. Для React и роутера ставят singleton: true и requiredVersion, иначе на странице окажутся две копии React и ошибка про хуки.

Главная польза в независимом релизе: команда каталога выкатывает свою часть, и хост подхватывает её без своего деплоя. Дальше развитие ушло в Module Federation 2.0 (@module-federation/enhanced): манифест, генерация типов для remote, runtime-плагины, поддержка Rspack и отдельный плагин для Vite. Знайте и альтернативы: single-spa, Native Federation на import maps, обычные npm-пакеты с версиями, если независимый деплой не нужен.

Где спотыкаются

Выдают Module Federation за способ уменьшить бандл. Ленивую загрузку даёт обычный code splitting, а федерация добавляет рантайм и сетевые запросы, её смысл в независимости команд.

Не продумывают отказ remote. Без error boundary и запасного интерфейса упавший сервис одной команды кладёт всю страницу.

Забывают про контракт между host и remote. Remote меняет пропсы компонента, и хост ломается в продакшене, а не на сборке. Спасают версионирование и общие типы.