Главная страница>Связанные с программированием>Другой исходный код
Скачать

Стандартная версия

standard-version устарела . Если вы пользователь GitHub, я рекомендую в качестве альтернативы. Если вы не можете использовать действия GitHub, или если вам нужно придерживаться standard-version по какой-то другой причине, вы можете использовать вилку Commit-and-Tag-версию standard-version .

Утилита для управления версиями с использованием генерации SEMVER и ChangerLog, основанного на обычных коммитах.

У вас проблемы? Хотите внести свой вклад? Присоединяйтесь к нам на сообществе узлов Slack .

Как это работает:

  1. Следуйте спецификации обычной коммиты в вашем хранилище.
  2. Когда вы будете готовы к выпуску, запустите standard-version .

standard-version затем сделает следующее:

  1. Получите текущую версию вашего репозитория, просмотрев packageFiles [1], вернувшись к последнему git tag .
  2. bump версию в bumpFiles [1] на основе ваших коммитов.
  3. Генерирует changelog на основе ваших коммитов (использует традиционную чагологу под капюшоном).
  4. Создает новый commit , включающий ваш bumpFiles [1] и обновленную изменение ChangeLog.
  5. Создает новый tag с новым номером версии.

bumpFiles , packageFiles и updaters

standard-version использует несколько ключевых концепций для обработки версии в вашем проекте.

  • packageFiles -пользовательские файлы, в которых версии можно прочитать и быть «удлиняемыми».
    • Примеры: package.json , manifest.json
    • В большинстве случаев (включая дефолт), packageFiles представляют собой подмножество bumpFiles .
  • bumpFiles -пользовательские файлы, в которых версии должны быть «удалены», но не чтение явно.
    • Примеры: package-lock.json , npm-shrinkwrap.json
  • updaters - Простые модули, используемые для чтения packageFiles и записи для bumpFiles .

По умолчанию standard-version предполагает, что вы работаете в проекте, основанном на Nodejs ... Из-за этого для большинства проектов вам, возможно, никогда не понадобится взаимодействовать с этими вариантами.

Тем не менее, если вы обнаружите, что вы спрашиваете, как я могу использовать стандартную версию для дополнительных файлов метаданных, языков или файлов версий? - Эти параметры конфигурации помогут!

Установка standard-version

Как локальный сценарий npm run

Установить и добавить в devDependencies : 

 npm i --save-dev standard-version

Добавьте сценарий npm run в свой package.json . 

{
  "scripts" : {
    "release" : " standard-version "
  }
}

Теперь вы можете использовать npm run release вместо npm version .

Это имеет преимущество в том, чтобы сделать ваш репо/пакет более портативным, так что другие разработчики могут сокращать выбросы без необходимости глобального установки standard-version на своей машине.

Как глобальный bin

Установите глобально (добавьте в свой PATH ): 

 npm i -g standard-version

Теперь вы можете использовать standard-version вместо npm version .

Это имеет преимущество, позволяя вам использовать standard-version в любом репо/пакете без добавления зависимости DEV в каждый.

Используя npx

По состоянию на [email protected] npx установлен вместе с npm . Используя npx , вы можете использовать standard-version без необходимости хранить файл package.json , работая: npx standard-version .

Этот метод особенно полезен при использовании standard-version в не Javascript Projects.

Конфигурация

Вы можете настроить standard-version либо по:

  1. Поместите standard-version строфы в свой package.json .
  2. Создание .versionrc , .versionrc.json или .versionrc.js .
  • Если вы используете .versionrc.js ваш экспорт по умолчанию должен быть объектом конфигурации или функцией, возвращающей объект конфигурации.

Любой из параметров командной строки, принятых standard-version может быть предоставлена ​​через конфигурацию. Пожалуйста, обратитесь к условному конфигу-Spec для получения подробной информации о доступных параметрах конфигурации.

Настройка генерации изменений

По умолчанию (по состоянию на 6.0.0 ) standard-version использует предварительную предварительную установку обычныхкоммитов.

Эта предустановка:

  • Придерживается внимательно к спецификации Fustrancommits.org.
  • Высоко настраивается, после спецификации конфигурации, поддерживаемой здесь.
    • Мы задокументировали эти настройки конфигурации в качестве рекомендации другим производителям инструментов.

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

В качестве примера, предположим, что вы используете gitlab, а не GitHub, вы можете изменить следующие переменные:

  • commitUrlFormat : формат URL -адреса Commit Shas, обнаруженного в сообщении Commit.
  • compareUrlFormat , что формат URL -адреса, используемый для сравнения двух тегов.
  • issueUrlFormat , формат URL -адреса, используемый для ссылки на проблемы.

Заставление этих URL -адресов соответствует формату Гитлаба, а не GitHub.

Использование CLI

Примечание. Чтобы перенести вложенные конфигурации в CLI, не определяя их в package.json eg --skip.changelog

Первый релиз

Чтобы сгенерировать вариант вашего первого выпуска, просто сделайте: 

 # npm run script
npm run release -- --first-release
# global bin
standard-version --first-release
# npx
npx standard-version --first-release

Это пометит релиз , не наткнувшись на версию bumpFiles 1 .

Когда вы будете готовы, нажмите The Git Tag и npm publish свой первый релиз. o/

Резкие релизы

Если вы обычно используете npm version , чтобы вырезать новый релиз, сделайте это вместо этого: 

 # npm run script
npm run release
# or global bin
standard-version

До тех пор, пока ваши сообщения о коммите GIT являются обычными и точными, вам больше не нужно указывать тип SEMVER - и вы получаете генерацию изменений в сфере управления бесплатно! o/

После того, как вы сократите релиз, вы можете протолкнуть новую тег GIT и npm publish (или npm publish --tag next ), когда вы будете готовы.

Выпустить как предварительный релиз

Используйте флаг --prerelease , чтобы генерировать предварительные передачи:

Предположим, что последняя версия вашего кода составляет 1.0.0 , а ваш код, который будет совершен, исправлено. Бегать: 

 # npm run script
npm run release -- --prerelease

Это пометит вашу версию: 1.0.1-0 .

Если вы хотите назвать предварительную релиз, вы указываете имя через --prerelease <name> .

Например, предположим, что ваш предварительный выпуск должен содержать префикс alpha : 

 # npm run script
npm run release -- --prerelease alpha

Это пометит версию как: 1.0.1-alpha.0

Выпустить в качестве целевого типа ( npm version -like)

Чтобы отказаться от автоматической версии использования BUMP --release-as с аргументом, major , minor или patch .

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

 # npm run script
npm run release -- --release-as minor
# Or
npm run release -- --release-as 1.1.0

Вы получите версию 1.1.0 , а не то, что будет авторизованной версией 1.0.1 .

Примечание. Вы можете объединить --release-as и --prerelease для создания релиза. Это полезно при публикации экспериментальных функций.

Предотвратить git крючков

Если вы используете Git Hooks, например, Pre-Commit, чтобы проверить свой код перед совершением совершения, вы можете предотвратить проверку крючков во время шага коммита, передавая опцию --no-verify : 

 # npm run script
npm run release -- --no-verify
# or global bin
standard-version --no-verify

Подписание коммитов и тегов

Если у вас есть настройка ключа GPG, добавьте флаг --sign или -s в команду standard-version .

Сценарии жизненного цикла

standard-version поддерживает сценарии жизненного цикла. Они позволяют вам выполнять свои собственные дополнительные команды во время релиза. Следующие крючки доступны и выполняются в задокументированном заказе:

  • prerelease : выполнено до того, как что -то случится. Если сценарий prerelease возвращает код выхода из ненулевого выхода, вывод версий будет прервано, но он не окажет другого влияния на процесс.
  • prebump / postbump : выполнено до и после того, как версия сталкивается. Если сценарий prebump возвращает версию #, он будет использоваться, а не версия, рассчитанная по standard-version .
  • prechangelog / postchangelog : выполняет до и после того, как сгенерировано изменение.
  • precommit / postcommit : вызван до и после шага коммита.
  • pretag / posttag : вызван до и после шага тега.

Просто добавьте следующее в свой Package.json, чтобы настроить сценарии жизненного цикла: 

{
  "standard-version" : {
    "scripts" : {
      "prebump" : " echo 9.9.9 "
    }
  }
}

В качестве примера для перехода с использования GitHub на отслеживание ваших элементов на использование ваших проектов Jira Используйте скрипт postchangelog , чтобы заменить фрагмент URL, содержащий «https://github.com/`myproject`/issues/» со ссылкой на вашу Jira - предполагаете, что вы уже установлены. 

{
  "standard-version" : {
    "scripts" : {
      "postchangelog" : " replace 'https://github.com/myproject/issues/' 'https://myjira/browse/' CHANGELOG.md "
    }
  }
}

Пропустить этапы жизненного цикла

Вы можете пропустить любой из шагов жизненного цикла ( bump , changelog , commit , tag ), добавив следующее в свой Package.json: 

{
  "standard-version" : {
    "skip" : {
      "changelog" : true
    }
  }
}

Совершение сгенерированных артефактов в выпуске

Если вы хотите совершить сгенерированные артефакты в выпуске, вы можете использовать флаг --commit-all или -a . Вам нужно будет поставить артефакты, которые вы хотите совершить, чтобы ваша команда release могла выглядеть так: 

{
  "standard-version" : {
    "scripts" : {
      "prerelease" : " webpack -p --bail && git add <file(s) to commit> "
    }
  }
}
{
  "scripts" : {
    "release" : " standard-version -a "
  }
}

Сухой режим пробега

Запуск standard-version с флагом --dry-run позволяет вам увидеть, какие команды будут выполнены, без привлечения GIT или обновления файлов. 

 # npm run script
npm run release -- --dry-run
# or global bin
standard-version --dry-run

Префикс теги

Теги префикс по v . Если вы хотите префикс свои теги чем -то другим, вы можете сделать это с флагом -t . 

standard-version -t @scope/package @

Это будет префикс ваши теги, чтобы выглядеть как @scope/[email protected]

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

ПРИМЕЧАНИЕ: просто -t или - -tag -prefix без какого -либо значения, выпадает на по умолчанию 'V'

CLI помощь 

 # npm run script
npm run release -- --help
# or global bin
standard-version --help

Использование кода 

 const standardVersion = require ( 'standard-version' )

// Options are the same as command line, except camelCase
// standardVersion returns a Promise
standardVersion ( {
  noVerify : true ,
  infile : 'docs/CHANGELOG.md' ,
  silent : true
} ) . then ( ( ) => {
  // standard-version is done
} ) . catch ( err => {
    console . error ( `standard-version failed with message: ${ err . message } ` )
} )

Совет: используйте silent опции, чтобы предотвратить печать standard-version на console .

Часто задаваемые вопросы

Чем standard-version отличается от semantic-release ?

semantic-release описывается как:

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

В то время как оба основаны на одной и той же основе структурированных сообщений о коммите, standard-version использует другой подход, обрабатывая управление версиями, генерацией изменений и GIT, помечая для вас без автоматического толкания (к GitHub) или публикации (в реестр NPM). Использование standard-version влияет только на ваше местное репо -репо - это вообще не влияет на удаленные ресурсы. После запуска standard-version вы можете просмотреть состояние выпуска, исправить ошибки и следить за стратегией выпуска, которая имеет наибольший смысл для вашей кодовой базы.

Мы думаем, что они оба являются фантастическими инструментами, и мы призываем людей использовать semantic-release вместо standard-version если это имеет смысл для их использования.

Должен ли я всегда раздавить коммиты при слиянии PRS?

Инструкции по спредам при объединении запросов на вытягивание предполагают, что один PR равняется, что больше всего, одна функция или исправление .

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

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

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

Могу ли я использовать standard-version для дополнительных файлов метаданных, языков или файлов версий?

Начиная с версии 7.1.0 вы можете настроить несколько bumpFiles и packageFiles .

  1. Укажите пользовательское « filename bumpFile , это путь к файлу, который вы хотите «ударить»
  2. Укажите « updater » bumpFile , так и будет , как будет удручен файл. а Если вы используете общий тип, вы можете использовать один из встроенных updaters standard-version , указав type . беременный Если вы используете файл версии, менее сообщающего, вы можете создать свой собственный updater . 
 // .versionrc
{
  "bumpFiles" : [
    {
      "filename" : "MY_VERSION_TRACKER.txt" ,
      // The `plain-text` updater assumes the file contents represents the version.
      "type" : "plain-text"
    } ,
    {
      "filename" : "a/deep/package/dot/json/file/package.json" ,
      // The `json` updater assumes the version is available under a `version` key in the provided JSON document.
      "type" : "json"
    } ,
    {
      "filename" : "VERSION_TRACKER.json" ,
      //  See "Custom `updater`s" for more details.
      "updater" : "standard-version-updater.js"
    }
  ]
}

При использовании .versionrc.js в качестве файла конфигурации, updater также может быть установлено в качестве объекта, а не как путь: 

 // .versionrc.js
const tracker = {
  filename : 'VERSION_TRACKER.json' ,
  updater : require ( './path/to/custom-version-updater' )
}

module . exports = {
  bumpFiles : [ tracker ] ,
  packageFiles : [ tracker ]
}

Пользовательский updater с

Ожидается, что updater будет модулем JavaScript с по крайней мере двумя выставленными методами: readVersion и writeVersion .

readVersion(contents = string): string

Этот метод используется для чтения версии из предоставленного содержимого файла.

Ожидается, что возвращаемое значение будет строкой семантической версии.

writeVersion(contents = string, version: string): string

Этот метод используется для написания версии в предоставленное содержимое.

Возвратное значение будет записано напрямую (перезаписывается) в предоставленный файл.

Давайте предположим, что у нашего VERSION_TRACKER.json есть следующее содержимое: 

{
  "tracker" : {
    "package" : {
      "version" : " 1.0.0 "
    }
  }
}

Приемлемым standard-version-updater.js будет: 

 // standard-version-updater.js
const stringifyPackage = require ( 'stringify-package' )
const detectIndent = require ( 'detect-indent' )
const detectNewline = require ( 'detect-newline' )

module . exports . readVersion = function ( contents ) {
  return JSON . parse ( contents ) . tracker . package . version ;
}

module . exports . writeVersion = function ( contents , version ) {
  const json = JSON . parse ( contents )
  let indent = detectIndent ( contents ) . indent
  let newline = detectNewline ( contents )
  json . tracker . package . version = version
  return stringifyPackage ( json , indent , newline )
}

Лицензия

ISC

Расширять
Дополнительная информация
Связанные приложения
Рекомендуем вам
Связанные новости Все