Лерна руководство по началу работы

1. Расположение

Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm.

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

PSLerna - это собственный ежедневный инструмент Babel с открытым исходным кодом, см. Почему Babel - монорепозиторий?

2. Monorepo
Monorepo (монолитный репозиторий), в отличие от multirepo, представляет собой репозиторий с одним кодом и репозиторий с несколькими кодами (один репозиторий на модуль).

Мультирепо - традиционный подход. Он разделен на несколько кодовых баз по модулям. На практике были обнаружены некоторые проблемы:

Управление проблемами происходит хаотично, и проблемы с модулями часто возникают в основном репозитории, и вам нужно закрыть это и отслеживать это.

Журнал изменений сложно интегрировать, и необходимо вручную отсортировать все измененные склады и интегрировать их

Обновление версии основного репо вызывает проблемы, вам необходимо синхронизировать все модули, чтобы обновить их зависимые версии основного репо.

Monorepo помещает все связанные модули в репо. Каждый модуль выпускается независимо, но использует тот же номер версии (например, Babel и React) с репо. Проблемы и PR сосредоточены в репо, и журнал изменений можно просто скопировать из одной копии. Список фиксации отсортирован (даже если тег проблемы связан со спецификацией фиксации, стандартизированный журнал изменений может быть автоматически создан)

У Monorepo тоже есть некоторые проблемы, но не такие сильные, как упомянутые выше болевые точки:

Размер репо большой, что может вызвать проблемы с контролем версий (Git не подходит для управления большим репо)

Унифицированные инструменты сборки, выдвигающие более высокие требования к инструментам сборки, чтобы иметь возможность создавать различные связанные модули

С точки зрения управления исходным кодом, multirepo и monorepo - это две разные концепции. Первая позволяет диверсифицировать разработку, и каждый модуль может иметь свой собственный игровой процесс (сборка, управление зависимостями, модульное тестирование и т. Д.), В то время как последний надеется централизовать управление и сократить игровой процесс. Затраты на связь, вызванные различиями

Отличительной чертой monorepo является структура каталогов, такая как React:

react-16.2.0/
  packages/
    react/
    react-art/
    react-.../

Каждый модуль имеет свои собственные зависимости (package.json), которые можно выпустить как независимый пакет npm, но исходный код поддерживается вместе.

Типичный случай:

свертка ： мультирепо

Babel ： monorepo

Если у вас возникли проблемы с накоплением перед использованием PS, сначала перейдите в главное репо, чтобы проверить связанные проблемы, затем найдите соответствующее репозиторий плагина в соответствии с подсказками, а затем проверьте связанные проблемы. Я всегда чувствовал себя очень обеспокоенным, и я не могу сказать, что случилось. Оказалось, что проблема связана с организацией исходного кода.

Three.lerna play

// 安装
npm install lerna -g
git init hoho-lerna && cd hoho-lerna
// 初始化目录结构
lerna init

Получим следующую структуру:

hoho-lerna/
  packages/
  lerna.json
  package.json

Создайте модуль:

mkdir packages/hoho-lerna-core && cd packages/hoho-lerna-core
npm init

В итоге получится куча пакетов:

packages/
  hoho-lerna-core/
    package.json
  hoho-lerna-module-a/
    package.json
  hoho-lerna-module-b/
    package.json
  module.../

На самом деле мы разбиваем на пакеты по модулям и объявляем зависимости между пакетами (через package.json на уровне модуля).

Обработка зависимостей
Если moduleA зависит от ядра, после обработки зависимости командой lerna bootstrap будет создана мягкая ссылка в node_modules модуля A, указывающая на каталог ядра. Это живой пример

Примечание: npm не будет автоматически устанавливать peerDependencies, и lerna не предоставляет эту услугу.

Lerna bootstrap фактически связывает пакеты, устанавливая мягкие ссылки в соответствии с ранее заявленными зависимостями.

Поскольку все пакеты выпуска помещены в пакеты, им легко управлять унифицированным способом, поэтому он поддерживает выпуск всех пакетов в npm одним щелчком мыши.

PS должен иметь учетную запись npm (саморегистрацию) и добавить npm adduser в локальную конфигурацию

После подготовки я не могу дождаться начала со стрелкой:

Если публикация lerna
не является неожиданной, вы получите аналогичный результат:

lerna info version 2.7.0
lerna info current version 0.0.0
lerna info Checking for updated packages...
lerna info Comparing with initial commit.
lerna info Checking for prereleased packages...
? Select a new version (currently 0.0.0) Major (1.0.0)

Changes:
 - hoho-lerna-core: 1.0.0 => 1.0.0
 - hoho-lerna-module-a: 1.0.0 => 1.0.0
 - hoho-lerna-module-b: 1.0.0 => 1.0.0

? Are you sure you want to publish the above changes? Yes
lerna info publish Publishing packages to npm...
lerna info published hoho-lerna-module-b
lerna info published hoho-lerna-core
lerna info published hoho-lerna-module-a
lerna info git Pushing tags...
Successfully published:
 - [email protected]
 - [email protected]
 - [email protected]
lerna success publish finished

Затем в реестре npm есть 3 нежелательных пакета ...

Общий процесс публикации:

Тег локально (например, git tag v1.0.0)

Пример автоматического обновления номера версии зависимости

Затем опубликуйте каждый пакет в npm

Наконец, нажмите тег и соответствующий коммит

Примечание. Если на этапе публикации в npm произошел сбой (например, учетная запись npm не настроена), следующую прямую публикацию lerna нельзя опубликовать напрямую, похоже, что локальный тег уже имеет версию 1.0.0 и последняя публикация прошла успешно. Невозможно вручную развернуть этот тег. Некоторые состояния выпуска могут быть записаны в .git. После откатывания появляется ошибка совпадения хэша фиксации, что здесь не очень удобно.

PS Для получения дополнительных команд, пожалуйста, проверьте Lerna

Чтобы автоматически создавать журнал
изменений, сначала установите инструмент журнала изменений:

npm install lerna-changelog -g

Затем добавьте соответствующие элементы конфигурации в lerna.json:

"changelog": {
  "repo": "ayqy/hoho-lerna",
  "labels": {
    "enhancement": ":rocket: Enhancement",
    "bug": ":bug: Bug Fix",
    "doc": "Refine Doc",
    "feat": "New Feature"
  },
  "cacheDir": ".changelog"
}

Специальное примечание: требуется репо, говорят, что он автоматически выводится, но на самом деле он не очень надежен, см. Автоматически выведенное поле репо не удалось, но ошибки не произошло

В PSlabels ключ - это метка, которая должна быть настроена в Github, используется для классификации проблемы / PR, значение в: bug: просто непослушный смайлик, оно будет использоваться как заголовок этого типа изменения в журнале изменений.

Это еще не конец, но вам также нужны разрешения на репозиторий Github (чтобы иметь возможность проверять Issue, PR) и выставлять токен как переменную среды (вы можете добавить его в ~ / .bash_profile, если вы обычно используете):

export GITHUB_AUTH="..."

Конфигурация завершена. Для достижения «автоматического» использования предполагается, что ежедневная разработка и сопровождение соответствуют согласованным спецификациям, в противном случае инструмент определенно не сможет угадать журнал изменений в конце. Спецификация относится к:

(Рекомендация) Соответствующая проблема, связанная с сообщением фиксации

(Обязательно) Выберите нашу предопределенную метку при создании PR

Поскольку инструмент сортирует PR только с указанной меткой на github и использует сообщение фиксации в качестве элемента журнала изменений, рекомендуется связать проблему в сообщении фиксации, а сгенерированный журнал изменений можно связать с соответствующей проблемой:

Uses github PR/Issue names categorized by labels with configurable headings.

Например:

git cm -m "feat: changelog, Close #1"

Затем отправьте PR и вставьте метку: feat, после слияния потяните локальный pull, чтобы попробовать lerna-changelog:

## Unreleased (2018-01-13)

#### New Feature
* [#2](https://github.com/ayqy/hoho-lerna/pull/2) feat: changelog, Closes [#1](https://github.com/ayqy/hoho-lerna/issues/1). ([@ayqy](https://github.com/ayqy))

#### Committers: 1
- 黯羽轻扬 ([ayqy](https://github.com/ayqy))
相当漂亮：https://github.com/ayqy/hoho-lerna/releases/tag/v1.1.0

PS должен игнорировать локально созданный временный файл журнала изменений в .gitignore, только локальный журнал изменений lerna-changelog при выпуске новой версии и публиковать сгенерированный журнал изменений в примечании к выпуску. Отсутствие автоматического выпуска примечаний к выпуску может быть вызвано ограничениями API или соображениями осторожности. В конце концов, примечания к выпуску по-прежнему важнее

Кроме того, автоматическая сортировка журнала изменений таким образом фактически зависит от ограничений в разработке (спецификация метки PR, сообщение фиксации в качестве спецификации элемента журнала изменений), что не имеет ничего общего с lerna, если это монорепозиторий (Issue / PR) Собрав их вместе, вы можете получить информацию о проблеме / PR в соответствии с этой идеей и отсортировать журнал изменений.

Это равносильно распределению огромной рабочей нагрузки по сортировке журнала изменений на ежедневную разработку и сопровождение. Изменение должно быть PR, и должна быть запись о проблеме. Если вы не привыкли к этому, это все еще очень хлопотно (есть призыв к сообщению о фиксации, чтобы принести свой собственный ярлык вместо PR , Он должен поддерживаться в будущем)

4. Применимые сценарии В
каких сценариях можно использовать monorepo (и использовать lerna management?)?

Но если это огромный проект, если у вас есть интегрированный исходный код 100G, подумайте об этом еще раз.

Для проектов с несколькими модулями и надстройками очень удобно использовать официально поддерживаемые надстройки в виде пакетов.

Кроме того, вам также понадобятся:

Инфраструктура

Командное доверие

Инфраструктура относится к мощному инструменту сборки, который может удовлетворить потребности сборки всех модулей (для чисто интерфейсного проекта давление сборки невелико)

В среде монорепозитория возможно и поощряется изменение кода других людей. С одной стороны, необходим механизм непрерывной интеграции (такой как React-CircleCI) для подтверждения влияния модификации. С другой стороны, разные команды должны доверять друг другу, иначе часто будет появляться одна команда. Изменение влияет на ситуацию другой команды и требует отката чужих изменений, что повлияет на эффективность.

PSLerna отсутствует давно (примерно ровесник Babel), и многие проекты уже используются

Справка
Лерна: очень краткий официальный документ

monorepo новая волна | представьте lerna: старший helloworld неплохой

Битва в стиле REPO: MONO VS MULTI

Сравнение инструментов Mono Repository: Сравнение инструментов Mono Repository

Модульность новой волны с организациями Lerna, monorepos и npm