Плейсхолдеры в версиях

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

Для примера, у нас включено сквозное версионирование на весь репозиторий, и мы создаем новый пакет zap@1.0.0, например, в одноименном бранче, и он зависит от пакета core@^1.0.0.

Далее в мастере пакет core обновился до версии 1.1.0:

Проблема

Что произойдет если мы смержим ветку zap ?

1. Версия пакета zap станет неконсистентной, согласно включенному сквозному версионированию. Мы конечно можем эту версию подправить в дальнейшем, но именно мерж-коммит так и останется неконсистентным.
2. Зависимость от core хоть и будет легитимной для версии 1.1.0, но, тем самым возникает риск что зависимость core для пакета zap будет версии 1.0.0, а не актуальная. Это возможно, например, если у пакета zap есть некоторая зависимость от пакета, который в свою очередь зависит от пакета core@1.0.0. В итоге npm или yarn может в целях оптимизации размера node_modules, поставить пакет core@1.0.0, когда нам нужен core@1.1.0.

Кроме того, версионирование через пакеты может нести проблемы и с независимыми версиями. При создании бранча, когда вы добавляете пакеты и новые зависимости на эти пакеты, могут появляться конфликты буквально с каждым обновлением мастера, которое также привносит изменения в эти зависимости.

Решение

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

Самый простой способ достичь этого это вообще прописать в коде всем константные версии-плейсхолдеры, а актуальное версионирование вынести в другое место, про которое npm или yarn знать не будут.

Для примера, пусть у нас будет пакет A:

{
  "name": "A",
  "version": "0.0.0-stub"
}

Зависимый от него будет выглядеть так:

{
  "name": "B",
  "version": "0.0.0-stub",
  "depenencies": {
    "A": "0.0.0-stub"
  }
}

При этом обновление пакетов не будет приводить к обновлению версий в мапе depenencies, что уберет проблему конфликтов в этом месте.

Публикация

Публикация пакетов при этом не пострадает, перед ней мы просто будем возвращать версии пакетов на место в package.json и только после этого публиковать пакеты.

соглашение о непубликуемых версиях

Внутри pvm есть соглашение что версия-плейсхолдер имеет вид 0.0.0-TAG, где TAG любая строка, которая вам подходит. Строка не должна начинаться на число.

выделенное версионирование

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

Где хранить настоящие версии

Ок, а где тогда хранить актуальные версии пакетов, которые будут использоваться при публикации ? Есть несколько вариантов:

Релизный тег

Все версии пакетов можем хранить в релизном теге. И в зависимости от настроек и количества пакетов брать версию из непосредственно имени релизного тега и/или его аннотации.

Соответствующие настройки в pvm

[versioning]
source = 'tag'

Файл

Также мы можем хранить версии в файле и сопоставлять имя пакета до нужной версии.

Соответствующие настройки в pvm

[versioning]
source = 'file'
# source_file = 'versions.json' # опционально, по умолчанию складывает в файл versions.json

tip

Если у вас еще нет этого файла, и вы только включили эту настройку, его можно проинициализировать командой yarn pvm lint --fix. Хотя это и не обязательно, все же наглядно посмотреть что изменится при релизе не помешает.

Тег на каждый пакет

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

caution

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

Соответствующие настройки в pvm

[versioning]
source = 'tag'

[tagging.for_packages]
enabled = true

В следующей части книги мы подведем итоги этой главы и рассмотрим все варианты версионирования, которые можно настроить с помощью pvm.