Micro Frontends Architecture with Module Federation · Урок

Общие зависимости и управление версиями

«Общие зависимости и управление версиями» — бесплатный урок Micro Frontends Architecture with Module Federation на CoddyKit. Это урок 4 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Micro Frontends Architecture with Module Federation, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Micro Frontends Architecture with Module Federation содержит 4 уроков всего.

Части этого урока еще не переведены и отображаются на английском.

Why Sharing Matters

In a Module Federation setup every remote can bundle its own copy of react, react-dom, or a design system. Without coordination, a single page may load three copies of React.

Shared dependencies let independently deployed apps agree on a single instance of a library at runtime, cutting payload and avoiding state bugs.

The shared Key

Both host and remotes declare a shared block in their ModuleFederationPlugin config. Webpack then negotiates which version actually loads.

new ModuleFederationPlugin({
  name: 'host',
  shared: {
    react: { singleton: true },
    'react-dom': { singleton: true }
  }
})

Singletons Explained

singleton: true forces one and only one copy across the whole app. This is essential for libraries that hold internal state, like React (hooks) or a router.

Without it, two React instances cause the dreaded Invalid hook call error.

Version Negotiation

Each shared module declares a requiredVersion. At load time Module Federation picks the highest compatible version among all that are offered.

shared: {
  react: {
    singleton: true,
    requiredVersion: '^18.2.0'
  }
}

Strict Version Mismatch

When a remote needs a version incompatible with the loaded singleton, Module Federation logs a warning and uses the existing one. With strictVersion: true it instead throws, surfacing the mismatch early.

shared: {
  react: { singleton: true, strictVersion: true, requiredVersion: '18.2.0' }
}

Eager vs Lazy Sharing

By default shared modules load asynchronously, which requires a bootstrap entry. Setting eager: true bundles the dependency into the initial chunk so no async boundary is needed.

Use eager only for the host shell; eager everywhere defeats the purpose of sharing.

shared: {
  react: { singleton: true, eager: true }
}

The bootstrap Pattern

Because shared modules resolve asynchronously, the standard pattern splits the entry into index.js (just an import) and bootstrap.js (the real app). This defers execution until the share scope is ready.

// index.js
import('./bootstrap');

// bootstrap.js
import App from './App';
// ... mount App

Sharing a Design System

A shared component library should usually be a singleton too, so theming context and CSS-in-JS instances are not duplicated.

shared: {
  '@acme/ui': { singleton: true, requiredVersion: '^3.0.0' }
}

Auto-Sharing from package.json

Instead of listing versions by hand, you can pass an array and let the plugin read versions from package.json. Tools like the Module Federation Enhanced plugin can even auto-share all dependencies.

shared: ['react', 'react-dom', 'react-router-dom']

Diagnosing Duplicate Copies

To confirm sharing works, inspect the Network tab: you should see one vendor chunk for the shared lib. Bundle analyzers and the runtime share scope (__webpack_share_scopes__.default) help debug.

Best Practices Summary

Singleton for stateful libs (React, router, stores).
Set requiredVersion to align teams.
Keep eager only on the host shell.
Audit bundles regularly for accidental duplicates.

Quick Check

Which option ensures only one instance of React loads across all micro frontends?

Recap

You learned how Module Federation shares dependencies: singletons for stateful libs, version negotiation via requiredVersion/strictVersion, eager vs lazy loading, and the bootstrap pattern. Proper sharing slashes bundle size and prevents subtle runtime bugs.

Часто задаваемые вопросы

Урок «Общие зависимости и управление версиями» бесплатный?

Да — полный текст урока «Общие зависимости и управление версиями» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Micro Frontends Architecture with Module Federation, подпишись на CoddyKit PRO. Курс Micro Frontends Architecture with Module Federation содержит 4 уроков всего.

Чему я научусь в уроке «Общие зависимости и управление версиями»?

Узнайте, как Module Federation предоставляет библиотеки нескольким микрофронтендам, как работают синглтоны и согласование версий и какие методы предотвращают дублирование пакетов и сбои во время выпо… Ты практикуешь Micro Frontends Architecture with Module Federation с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать Micro Frontends Architecture with Module Federation?

Предыдущий опыт не требуется. Micro Frontends Architecture with Module Federation на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 4 из 4.

Сколько времени занимает урок «Общие зависимости и управление версиями»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке Micro Frontends Architecture with Module Federation?

Да. Каждый урок Micro Frontends Architecture with Module Federation включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

← Назад к Micro Frontends Architecture with Module Federation