Что такое shared-библиотеки между микрофронтами и как их правильно использовать?

Shared-библиотеки (или общие библиотеки) в архитектуре микрофронтов — это механизм для вынесения повторяющегося кода в отдельные пакеты, которые затем могут импортироваться независимыми командами, разрабатывающими разные части приложения. Это необходимо, чтобы избежать дублирования таких сущностей, как UI-компоненты (кнопки, модальные окна), утилиты для форматирования данных, клиенты API, константы или определения TypeScript-типов.

Основные подходы к организации

Существует несколько стратегий управления общими библиотеками:

• Монорепозиторий (Monorepo): Все микрофронты и shared-библиотеки находятся в одном репозитории. Инструменты вроде Nx, Lerna или Turborepo упрощают управление зависимостями, скриптами сборки и версионированием внутри репозитория. Изменения в библиотеке сразу видны всем зависимым проектам, что упрощает синхронизацию, но требует дисциплины, чтобы не нарушить обратную совместимость.
• Отдельные npm-пакеты: Библиотеки публикуются в приватный или публичный npm-реестр. Каждый микрофронт устанавливает их как обычные зависимости, указывая конкретную версию. Это даёт больше изоляции, но требует ручного обновления версий в каждом проекте и может привести к ситуации, когда разные микрофронты используют разные мажорные версии одной библиотеки.
• Динамическое подключение (Module Federation): Технология Webpack 5 Module Federation позволяет загружать код общих библиотек динамически во время выполнения из одного источника (host). Это уменьшает размер бандлов и гарантирует, что все микрофронты используют одну и ту же скомпилированную версию библиотеки в рантайме.

Правила использования и лучшие практики

• Минимизация зависимостей: Сама shared-библиотека должна иметь как можно меньше внешних зависимостей, особенно тяжёлых или конфликтующих.
• Семантическое версионирование (SemVer): Строгое соблюдение правил SemVer (MAJOR.MINOR.PATCH) для обратной совместимости. Изменения, ломающие API, — только в мажорных версиях.
• Инверсия зависимостей: Библиотека не должна зависеть от бизнес-логики конкретного микрофронта. Она предоставляет абстракции и примитивы.
• Тестирование: Обязательно покрытие библиотеки unit- и интеграционными тестами, так как её поломка затронет множество проектов.

Пример структуры в монорепозитории

// Структура проекта с использованием Nx
my-org/
├── apps/
│   ├── mf-auth/          # Микрофронт "Авторизация"
│   └── mf-dashboard/     # Микрофронт "Дашборд"
└── libs/
    └── shared-ui/        # Общая UI-библиотека
        ├── src/
        │   ├── Button.tsx
        │   └── index.ts  # Экспорт компонентов
        ├── project.json  # Конфигурация Nx
        └── jest.config.js

// Код компонента Button из shared-ui
import React from 'react';

type ButtonProps = {
  label: string;
  onClick: () => void;
};

export const Button: React.FC = ({ label, onClick }) => {
  return (
    
      {label}
    
  );
};

// Использование в микрофронте mf-auth
import { Button } from '@my-org/shared-ui';

const LoginForm = () => {
  return (
    
       console.log('Clicked')} 
      />
    
  );
};

Вывод: Shared-библиотеки стоит применять для стабильного, хорошо протестированного кода, который действительно используется в нескольких командах. Они помогают поддерживать единообразие интерфейса и сокращают затраты на разработку, но добавляют сложность управления зависимостями. Оптимальный подход — монорепозиторий с инструментами автоматизации для средних и крупных проектов, где важна скорость синхронизации изменений.