Похоже, что npm в основном строится вокруг концепции, согласно которой номер версии был записан в поле version файла package.json. Такие инструменты, как npm version и npm publish, должны управлять этим полем version и использовать его. Можно пометить выпуск в git через npm version, но не наоборот.
Мне интересно, я единственный, кто считает это неудобным. Мой вариант использования следующий:
- Я хотел бы использовать git как единственный источник правды относительно версии. Версия определяется только по соответствующему тегу git. В зафиксированном источнике версия
package.json должна содержать заполнитель, который заменяется при выпуске релиза. - Выпуск в репозиторий должен выполняться через этап конвейера CI, поэтому, когда я помечаю фиксацию в git, это должно запустить конвейер CI, и как часть этого конвейера выполняется выпуск, генерирующий пакет. json с допустимым номером версии. Версия должна быть получена из git, чтобы получить версии, аналогичные тем, которые созданы с помощью
git describe. - Версия также встроена в пакет выпуска, так что я могу получить к ней доступ во время выполнения через переменную версии во время в процессе сборки версия извлекается из git через
git describe и встраивается в комплект поставки.
Это имеет несколько преимуществ:
- Мне не нужно для управления версией в двух разных местах (например, git и package. json), рискуя тем, что они расходятся.
- Я могу использовать механизм тегов git для запуска выпусков на основе CI в репозиторий.
- Если я собираю версию без тегов, я получаю номера версий, такие как 1.0.0-1-cfa549a3, которые делают очевидным, что я работаю с невыпущенной сборкой.
- Я знаю, когда грязная сборка была сделана из рабочего каталога.
Я знаю о semanti c -release, который может решить некоторые из этих проблем, но также вводит строгие требования к формату c пропускать сообщения. Поэтому мне интересно, есть ли какие-либо альтернативы, о которых я еще не знаю.
Следующий вопрос описывает аналогичную проблему: npm publi sh с информацией git вместо версии из пакет. json