Как организовать совместное использование утилит между несколькими командами?

Организация совместного использования утилит между несколькими командами

В современных проектах часто возникает ситуация, когда несколько команд (frontend, backend, DevOps) нуждаются в одних и тех же утилитах. Правильная организация общего кода критична для снижения дублирования, ускорения разработки и поддержки консистентности.

Архитектурные подходы

1. Монорепозиторий (Monorepo)

Самый популярный подход для больших организаций. Все команды работают в одном репозитории, но с разделением по пакетам.

// packages/shared-utils/src/format.js
export function formatDate(date) {
  return new Intl.DateTimeFormat('en-US', {
    year: 'numeric',
    month: 'long',
    day: 'numeric'
  }).format(date);
}

// packages/frontend/src/components/UserCard.tsx
import { formatDate } from '@shared/utils';

export function UserCard({ user }) {
  return <div>{formatDate(user.createdAt)}</div>;
}

// packages/backend/src/serializers.ts
import { formatDate } from '@shared/utils';

const userData = {
  createdAt: formatDate(new Date())
};

Для управления монорепозиторием используют инструменты:

• pnpm workspaces — встроенное управление зависимостями
• Lerna — автоматизация публикации версий
• Nx — оркестрация сборки и тестирования
• Turborepo — оптимизация задач с кешированием

2. Отдельный пакет (Package Repository)

Утилиты опубликованы как отдельный npm-пакет в приватном реестре.

// В package.json каждого проекта
{
  "dependencies": {
    "@company/shared-utils": "^1.2.3"
  }
}

// Использование
import { formatDate, validateEmail } from '@company/shared-utils';

Преимущества:

• Независимая версионирование
• Четкие границы между модулями
• Возможность использовать разные версии в разных проектах

Недостатки:

• Сложнее синхронизировать изменения
• Дополнительное управление версиями

Практические инструменты

pnpm Workspaces (рекомендую)

Легко настраивается и хорошо масштабируется:

// pnpm-workspace.yaml
packages:
  - 'packages/*'
  - 'apps/*'

# Добавить зависимость в shared-utils для всех
pnpm -w add lodash-es -r

# Установить зависимость между пакетами
cd packages/frontend
pnpm add @company/shared-utils@workspace:*

Структура типичного монорепо

project/
├── packages/
│   ├── shared-utils/
│   │   ├── src/
│   │   │   ├── formatters.ts
│   │   │   ├── validators.ts
│   │   │   └── api-client.ts
│   │   ├── package.json
│   │   └── tsconfig.json
│   ├── frontend/
│   └── backend/
├── pnpm-workspace.yaml
├── pnpm-lock.yaml
└── turbo.json (опционально)

Типизация и безопасность

Для TypeScript проектов используй общие типы:

// packages/shared-utils/src/types.ts
export interface User {
  id: string;
  email: string;
  name: string;
  createdAt: Date;
}

export interface ApiResponse<T> {
  data: T;
  error: string | null;
}

// packages/frontend и packages/backend импортируют эти типы
import { User, ApiResponse } from '@company/shared-utils';

Лучшие практики

1. Четкое разделение: utility пакет должен содержать только переиспользуемый код
2. Семантическое версионирование: выпускай патчи/минор/мажор изменения правильно
3. Документация: каждая утилита должна иметь примеры использования
4. Тесты: shared-utils требует high coverage (90%+), т.к. от них зависят другие части
5. CI/CD: проверяй, что изменения в утилитах не ломают зависящие проекты

Монорепо + pnpm + TypeScript — оптимальное сочетание для большинства компаний среднего размера.