Налаштування monorepo з Lerna: версіонування, CI/CD

Керування кількома десятками пакетів в одному репозиторії без автоматизації призводить до хаосу: ручне версіонування, конфлікти міжпакетних залежностей, дублювання коду. Кожна нова фіча вимагає синхронізації кількох пакетів, що вручну займає години. Lerna вирішує ці проблеми, надаючи єдиний інтерфейс для версіонування, збірки та публікації. Наш досвід налічує понад п'ятдесят monorepo-проєктів, і Lerna залишається основним вибором для бібліотек та утиліт, що публікуються в npm. Це фундамент для масштабування кодової бази без болю. Нижче — детальний розбір того, як ми налаштовуємо Lerna під ключ: від аналізу до CI/CD та документації. Отримайте консультацію інженера, щоб оцінити, чи підходить Lerna для вашого проєкту.

Чому Lerna, а не Turborepo чи Nx?

Lerna має сенс, коли проєкт — бібліотека або набір пакетів, які публікуються в npm. Потрібне автоматичне керування версіями (semver) та CHANGELOG. Команда невелика, складна інфраструктура надлишкова. Для закритого продукту без публікації — краще Turborepo або Nx. Lerna 6+ відродився під управлінням Nrwl з опціональним Nx під капотом для кешування та паралельного виконання завдань. Економія часу на збірці сягає 50% при 20+ пакетах.

Налаштування Lerna: покроковий процес

Аналіз та конфігурація

Починаємо з визначення режиму: independent або fixed. Узгоджуємо стек, CI-провайдера, менеджер пакетів. pnpm прискорює встановлення на 30% і економить до 50% дискового простору за рахунок дедуплікації. Ініціалізуємо Lerna, налаштовуємо lerna.json, workspaces, підключаємо commitlint та husky для контролю conventional commits. Навчання команди займає 2–3 години.

npx lerna init --packages="packages/*" --independent

Приклад lerna.json:

{
  "$schema": "node_modules/lerna/schemas/lerna-schema.json",
  "version": "independent",
  "npmClient": "pnpm",
  "command": {
    "publish": {
      "conventionalCommits": true,
      "createRelease": "github",
      "message": "chore(release): publish",
      "registry": "https://registry.npmjs.org",
      "allowBranch": ["main", "next"]
    },
    "version": {
      "conventionalCommits": true,
      "conventionalChangelogConfig": "@conventional-changelog/conventionalcommits",
      "changelogPreset": "angular",
      "gitTagVersion": true,
      "push": true
    },
    "bootstrap": {
      "npmClientArgs": ["--no-package-lock"]
    }
  },
  "useWorkspaces": true,
  "useNx": true
}

Структура репозиторію

Організовуємо пакети в packages/: наприклад, button, input, modal. Кожен пакет — незалежна одиниця з tsconfig та тестами. Для документації використовуємо apps/docs (Storybook).

my-ui-library/
├── packages/
│   ├── button/
│   ├── input/
│   ├── modal/
│   ├── table/
│   └── theme/
├── apps/
│   └── docs/
├── package.json
├── lerna.json
└── pnpm-workspace.yaml

Управління версіями та публікація

При запуску lerna version відбувається визначення змінених пакетів, пропозиція нових версій за semver, оновлення package.json та міжпакетних залежностей, генерація CHANGELOG.md, створення git-коміту та тегів. Весь процес займає менше 5 хвилин для 20 пакетів.

Як Lerna інтегрується з CI/CD?

Пайплайн будується на GitHub Actions або GitLab CI. Ключовий момент — автоматична публікація тільки при злитті в main. Використовуємо lerna version --conventional-commits --yes для генерації версії та changelog, потім lerna publish from-git для публікації. Для масштабування вмикаємо useNx: true — це дає кешування та паралельне виконання завдань, скорочуючи час збірки до 10 хвилин навіть для 50+ пакетів. В результаті реліз займає 15 хвилин замість кількох годин, що знижує витрати на CI/CD на 30–40%.

# .github/workflows/release.yml
name: Release
on:
  push:
    branches: [main]

permissions:
  contents: write
  packages: write

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          token: ${{ secrets.GITHUB_TOKEN }}

      - uses: pnpm/action-setup@v3

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          registry-url: 'https://registry.npmjs.org'

      - run: pnpm install --frozen-lockfile

      - name: Build all packages
        run: npx lerna run build

      - name: Version and publish
        run: |
          git config user.email "[email protected]"
          git config user.name "CI Bot"
          npx lerna version --conventional-commits --yes --no-push
          npx lerna publish from-git --yes
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Запуск завдань з Nx під капотом

Lerna 6+ використовує Nx для розумного запуску:

npx lerna run build
npx lerna run test --since=main
npx lerna run build --scope=@acme/modal --include-dependents

Кешування Nx дозволяє повторно використовувати результати збірки, економлячи до 70% часу при повторних запусках. Це особливо важливо для великих monorepo з сотнями пакетів.

Independent чи fixed mode?

Для бібліотек компонентів або утиліт, які випускаються асинхронно, independent mode — єдиний розумний вибір. Кожен пакет версіонується незалежно, що дозволяє виправляти баги в одному пакеті без впливу на інші. У fixed mode, як у React або Vue, всі пакети синхронізовані — це простіше, але менш гнучко. Ми рекомендуємо independent mode для проєктів з різною частотою релізів. Економія часу на узгодженні версій становить 2–3 години на тиждень.

Що входить до налаштування

• Повністю сконфігурований monorepo з Lerna та обраним менеджером пакетів (pnpm/npm/yarn)
• CI/CD пайплайн (GitHub Actions або GitLab CI) для автоматичної публікації при злитті в main
• Документація процесу релізу з правилами conventional commits
• Онбординг команди (демо-сесія 2–4 години)
• Підтримка протягом 2 тижнів після впровадження: виправлення помилок, консультації

Окупність такого налаштування — менше 3 місяців за рахунок скорочення ручної праці та помилок при релізі.

Типові складнощі

При оновленні версії через lerna version залежність може не оновитися, якщо вказано м'який діапазон (^ або ~). Прапорець --force-publish оновлює всі пакети примусово, а хардкодні версії (без caret) гарантують оновлення. CHANGELOG може дублювати записи — використовуйте --changelog-include-commits-root-path якщо потрібні кореневі коміти. Публікація на CI може впасти через npm publish --dry-run у .npmrc — переконайтеся, що dry-run=false у CI середовищі.

Строки та вартість

Налаштування Lerna для набору npm-пакетів з нуля займає від 2 до 5 днів залежно від складності. Вартість розраховується індивідуально. Зв'яжіться з нами для оцінки вашого проєкту та отримайте консультацію інженера з багаторічним досвідом у JavaScript-екосистемі. Замовте налаштування monorepo під ключ і переконайтеся в ефективності автоматизації.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.