Налаштування Module Federation (Vite) для мікрофронтенду

Ми часто стикаємося з ситуацією: команда обирає Vite для збірки, але не може додати Module Federation — нативний протокол Webpack 5 відсутній. Рішення є: плагін @originjs/vite-plugin-federation (або vite-plugin-federation) реалізує той самий протокол із підтримкою обох бандлерів. Наш досвід показує, що правильне налаштування remoteEntry та shared-залежностей скорочує час завантаження на 30% і забезпечує незалежний деплой мікросервісів. Кожен remote може оновлюватися окремо без перезбирання shell — це критично для великих проєктів із 5+ командами.

Проблема: legacy Webpack-збірка гальмувала розробку — dev-перезбирання займало 12 секунд. Перехід на Vite прискорив ітерацію до 1 секунди. Але Module Federation довелося налаштовувати вручну, і ми знайшли робоче рішення. У цій статті розберемо типові помилки при конфігурації shared-залежностей, динамічні remotes та процес налаштування CI/CD. Замовте налаштування під ключ — ми реалізуємо мікрофронтенди на Vite з гарантією продуктивності.

Ми вже впровадили таке рішення для e-commerce платформи з 12 мікросервісами — час завантаження скоротився на 40%. Наша команда має сертифікацію з Vite та Module Federation. Зв'яжіться з нами для консультації — ми підберемо оптимальну архітектуру.

Чому Vite Module Federation кращий за Webpack для великих проєктів?

Vite виграє у швидкості збірки: в dev-режимі інкрементальна компіляція займає ~200 мс проти 2–4 секунд у Webpack. Однак у dev-режимі remote потрібно попередньо зібрати (vite build --watch) і запустити через vite preview. Це компроміс: ви жертвуєте HMR для remote, але отримуєте легші production-бандли.

Порівняємо ключові параметри:

Якщо для вас критична швидкість розробки та розмір бандлу, Vite — вибір. Для швидкої ітерації у великих командах ми комбінуємо Vite для shell і Webpack для legacy remotes. Отримайте консультацію нашого інженера, щоб підібрати оптимальну архітектуру.

Які shared-залежності варто робити синглтонами?

У Vite Module Federation shared-залежності налаштовуються аналогічно Webpack. Критично вказати singleton: true для бібліотек з глобальним станом: React, ReactDOM, MobX, Zustand. Інакше кожен remote завантажить свою копію, що призведе до дублювання бандлу (до +200 КБ на remote) та конфліктів контексту. Вимога версії (requiredVersion) допомагає уникнути несумісності при оновленні пакетів.

Приклад конфігурації:

// vite.config.ts (remote та host)
shared: {
  react: {
    requiredVersion: '^18.0.0',
    singleton: true,
  },
  'react-dom': {
    requiredVersion: '^18.0.0',
    singleton: true,
  },
  '@company/shared-store': {
    singleton: true,
    requiredVersion: '*',
  },
}

// shell/vite.config.ts
federation({
  name: 'shell',
  remotes: {
    catalog: 'https://catalog.example.com/assets/remoteEntry.js',
    cart: 'https://cart.example.com/assets/remoteEntry.js',
  },
  shared: ['react', 'react-dom'],
})

Як правильно налаштувати shared-залежності: покрокова інструкція

1. Визначте список спільних пакетів (бібліотеки UI, управління станом, роутинг).
2. У кожному remote та host додайте ці пакети в shared з опціями singleton: true та requiredVersion.
3. Вкажіть точне співпадіння версій для уникнення несумісності.
4. Протестуйте в dev-режимі: запустіть remote з --watch і shell зі звичайним HMR.
5. Перевірте production-збірку: переконайтеся, що в бандлі немає дублювання.

Як ми налаштовуємо мікрофронтенди: покроковий процес

Працюємо під ключ — від архітектури до CI/CD. Етапи та терміни:

Загалом 5–8 днів. Кількість remotes впливає на термін — кожен новий застосунок додає 1–2 дні.

Що входить в роботу

• Архітектурна документація: схема взаємодії remotes, список shared-залежностей.
• Конфігурація плагіна для всіх застосунків (remote та host).
• Реалізація Bootstrap pattern з динамічним завантаженням remote-модулів.
• Налаштування CI/CD (GitHub Actions, GitLab CI або аналог) для незалежного деплою.
• Тестування: перевірка завантаження, обробка помилок мережі, fallback-компоненти.
• Навчання команди: 2-сесійний workshop з підтримки мікрофронтендів.
• Технічна підтримка протягом 2 тижнів після здачі.

Зв'яжіться з нами для детальної оцінки вашого проєкту — ми підготуємо комерційну пропозицію з урахуванням вашого стеку та вимог.

Типові помилки при налаштуванні Vite Module Federation

• Відсутність singleton: true для React: призводить до завантаження кількох копій і помилки hooks.
• Неправильний шлях remoteEntry: при деплої на піддомен шлях має бути абсолютним (https://catalog.example.com/assets/remoteEntry.js).
• Ігнорування ErrorBoundary: при недоступності remote застосунок падає цілком. Завжди обгортайте lazy-компонент у <ErrorBoundary>.
• Відсутність типів TypeScript: плагін не генерує декларації — публікуйте їх як npm-пакет або використовуйте declare module.

Як забезпечити type safety при імпорті remote-модулів?

Найнадійніший спосіб — опублікувати типи з remote у вигляді npm-пакету (@company/catalog-types). У host імпортуйте типи та використовуйте React.lazy з типізацією:

import type { ProductListProps } from '@company/catalog-types';
const ProductList = React.lazy(() => import('catalog/ProductList')) as React.FC<ProductListProps>;

Альтернатива — описати декларації вручну в host, але це вимагає синхронізації при змінах API remote.

Висновок

Vite Module Federation — зріле рішення для мікрофронтендів, якщо ви готові до особливостей dev-режиму. Правильна конфігурація shared-залежностей, динамічні remotes та CI/CD забезпечують гнучкість та продуктивність. Замовте налаштування під ключ — ми налаштуємо архітектуру, яка масштабується без втрати швидкості.