Процесс выпуска

Экспериментальная функция

Эта функция всё ещё находится в стадии разработки, и, вероятно, мы будем улучшать её на основе ваших отзывов.

Плагин

Для доступа к этой функции сначала установите плагин version: yarn plugin import version

При работе с монорепозиториями часто возникает сложная задача определения, какие пакеты должны получить новую версию при запуске нового выпуска. Yarn предлагает несколько инструментов, призванных упростить этот процесс без необходимости использования сторонних инструментов (хотя, конечно, вы можете предпочесть другой подход, предлагаемый другими реализациями!).

Автоматически обновляемые зависимости

При выполнении команды yarn version для обновления версии рабочего пространства все другие рабочие пространства, которые зависят от первого через базовые диапазоны semver (^x.y.z, ~x.y.z, ...), будут автоматически обновлены для ссылки на новую версию. Например, давайте рассмотрим следующие рабочие пространства:

/packages/common (1.0.0)
/packages/server (depends on common@^1.0.0)
/packages/client (depends on common@^1.0.0)

В версиях до 2.0 для обновления common вам нужно было запустить команду там, а затем вручную обновить зависимости в каждом из server и client, чтобы ссылаться на новую версию. Но теперь это не нужно! Если мы запустим yarn version 1.1.1 в common, будут применены следующие изменения:

/packages/common (1.1.1)
/packages/server (depends on common@^1.1.1)
/packages/client (depends on common@^1.1.1)

Конечно, это не так важно, когда пакеты из монорепозитория всегда предназначены для использования в рамках монорепозитория, но становится намного интереснее, когда вы работаете с несколькими пакетами, предназначенными для публикации. Если вы забудете обновить диапазон одного из ваших зависимых пакетов, ваши пользователи, возможно, загрузили старую версию common, которая не будет совместима с новой.

Отложенная версия

Начиная с версии 2.0, команда yarn version теперь принимает новый флаг: --deferred. При установке этого флага команда не будет сразу изменять поле version локального манифеста, а вместо этого внутренне запишет запись, указывающую, что текущий пакет должен быть обновлён в следующем цикле выпуска. Например, следующее:

yarn version minor --deferred

Не вызовет изменения файла package.json! Вместо этого Yarn создаст (или повторно использует, если вы находитесь в ветке) файл в каталоге .yarn/versions. Этот файл будет записывать запрашиваемое обновление:

releases:
  my-package@1.0.0: minor

Затем, когда вы будете готовы, просто запустите yarn version apply. Yarn найдёт все записи об обновлениях, которые он ранее сохранил, и применит их все сразу (включая обновление взаимозависимостей, как мы видели ранее).

Зафиксированные отложенные записи

В предыдущем разделе мы видели, что yarn version patch может хранить будущие версии во внутренней папке .yarn/versions. Но зачем это? Для ответа на этот вопрос рассмотрим популярный открытый проект, разработанный через монорепозиторий. Этот проект получает много внешних запросов на вытягивание, но они не выпускаются сразу — часто они выпускаются как часть пакета. Время от времени ведущий разработчик возьмёт все изменения, преобразует их в новые версии и начнёт развёртывание.

Давайте сосредоточимся на части, где изменения должны быть преобразованы в версии. Как это работает? Это не так просто. Например, с использованием Lerna (наиболее популярного инструмента управления версиями для монорепозиториев) у вас есть два решения:

• В режиме фиксирования все ваши пакеты имеют одинаковую версию. Таким образом, они обновляются все сразу.

• В режиме независимости вы можете выбрать версию для каждого пакета, исходные коды которого были изменены.

Однако остаётся одна критическая проблема: даже если вы используете режим независимости, как вы узнаете, какие пакеты необходимо обновить? И, что не менее важно, должны ли это быть обновления с пометкой патча, или мажора? Сложно знать — в крупные проекты могут поступать десятки запросов на вытягивание в неделю, и отслеживание того, какие модули нужно выпустить и до какой версии, — довольно сложная задача.

Однако с помощью рабочего процесса Yarn все это становится очень просто! Поскольку обновления хранятся в файле, и поскольку этот файл магически связан с веткой Git, всё сводится к тому, чтобы зафиксировать папку с выпуском — все ожидаемые выпуски затем станут частью истории проекта до момента yarn version apply — тогда Yarn прочитает все отдельные записи, объединит их (так что запрос на вытягивание, требующий мажора, будет иметь больший приоритет, чем запрос, требующий патча), и применит их одновременно.

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

Обеспечение повышения версий (CI)

Однако одна проблема с фиксированием отложенных выпусков заключается в том, что важно убедиться, что в запросах на вытягивание включены правильные определения выпусков пакетов. Например, вы должны иметь возможность доверять, что определение содержит стратегии выпуска (патч, мажор, мейджор, ...) для каждого изменённого рабочего пространства.

Для решения этой проблемы автоматическим способом появилась команда yarn version check. При выполнении этой команды будет определено, какие пакеты были изменены и указаны ли они в файле определения выпуска. Если нет, будет выброшено исключение, и — предполагая, что вы интегрируете это в систему непрерывной интеграции, например, GitHub Actions — автору запроса на вытягивание будет предложено заполнить файл определения выпуска.

Заполнение этого файла может быть утомительным; к счастью, yarn version check реализует очень удобный флаг под названием --interactive. При установке (yarn version check --interactive), Yarn отобразит интерфейс терминала, который предоставит сводку всех изменённых файлов, всех изменённых рабочих пространств, всех соответствующих зависимых рабочих пространств и флажки для каждого элемента, позволяющие выбрать стратегии выпуска, которые вы хотите установить для каждого рабочего пространства.

Настройка changesetIgnorePatterns может быть использована для игнорирования файлов при проверке, какие файлы были изменены. Это полезно для исключения файлов, которые не влияют на процесс выпуска (например, файлы тестов).

Примечание

История коммитов

Плагину version требуется доступ к истории коммитов, чтобы правильно определить, какие пакеты требуют спецификаций выпуска. В частности, при использовании GitHub Actions с actions/checkout@v2 или выше, по умолчанию Git получает только проверяемую версию, что может вызвать проблемы. Для исправления этого вам необходимо переопределить значение конфигурации fetch-depth для получения всей истории коммитов:

- uses: actions/checkout@v2
  with:
    fetch-depth: 0