standard version
v9.5.0
standard-version被弃用。如果您是GitHub用户，我建议您释放 - 替代方案。如果您无法使用github操作，或者由于某些其他原因需要坚持使用standard-version，则可以使用standard-version的提交和标签叉。
使用SEMVER和ChangElog生成的实用程序，该实用程序由传统提交提供动力。
有问题？想贡献吗？加入我们的节点 - 动静社区懈怠。
它的工作原理：
standard-version 。然后， standard-version将执行以下操作：
packageFiles [1]来检索存储库的当前版本，回到最后一个git tag 。bumpFiles [1]中bump版本。changelog （在引擎盖下使用常规变性）。commit ，包括您的bumpFiles [1]和更新的ChangElog。tag 。bumpFiles ， packageFiles和updaters standard-version使用一些关键概念来处理项目中的版本。
packageFiles - 用户定义的文件，可以从中读取版本并“颠簸”。package.json ， manifest.jsonpackageFiles是bumpFiles的子集。bumpFiles - 用户定义的文件，其中应“凸起”版本，但不明确阅读。package-lock.json ， npm-shrinkwrap.jsonupdaters - 简单的模块，用于读取packageFiles和写入bumpFiles 。默认情况下， standard-version假设您正在基于Nodejs的项目中工作...因此，对于大多数项目，您可能永远不需要与这些选项进行交互。
也就是说，如果您发现自己询问如何使用标准版本来获取其他元数据文件，语言或版本文件？ - 这些配置选项将有所帮助！
standard-versionnpm 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 npx standard-version可以使用standard-version ，而无需保留package.json 。
当在非JavaScript项目中使用standard-version时，此方法特别有用。
您可以standard-version ：
package.json中放置一个standard-version节（假设您的项目是JavaScript）。.versionrc ， .versionrc.json或.versionrc.js 。.versionrc.js则默认导出必须是配置对象，或返回配置对象的函数。可以通过配置提供由standard-version接受的任何命令行参数。有关可用配置选项的详细信息，请参考传统的变成config-spec。
默认情况下（截至6.0.0 ）， standard-version使用常规通信预设。
这个预设：
您可以转动各种表盘和旋钮，与ChangElog Generation相关。
例如，假设您使用的是gitlab而不是github，您可以修改以下变量：
commitUrlFormat ：在提交消息中检测到的提交SHA的URL格式。compareUrlFormat ：用于比较两个标签的URL格式。issueUrlFormat ：用于链接到问题的URL格式。使这些URL匹配Gitlab的格式，而不是Github的格式。
注意：要将嵌套配置传递给CLI而不在
package.json中定义它们。JSON使用DOT符号作为参数eg --skip.changelog。
要生成您的ChangElog作为第一个版本，只需做：
# npm run script
npm run release -- --first-release
# global bin
standard-version --first-release
# npx
npx standard-version --first-release这将标记发行版，而不会碰撞版本bumpFiles 1 。
准备就绪后，按GIT标签， npm publish您的第一个版本。 o/
如果通常使用npm version剪切新版本，请这样做：
# npm run script
npm run release
# or global bin
standard-version只要您的git提交消息是常规且准确的，您就不再需要指定SEMVER类型 - 您可以免费获得ChangElog生成！ 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 - 类）发布放弃使用自动化版本的使用--release-as与参数major ， minor或patch一样。
假设您的代码的最后一个版本是1.0.0 ，您只会降落fix:提交，但是您希望下一个版本成为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挂钩（例如预先承诺）在提交之前测试代码，则可以通过传递--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 ：在标签步骤之前和之后打电话。只需将以下内容添加到您的软件包。json即可配置生命周期脚本：
{
"standard-version" : {
"scripts" : {
"prebump" : " echo 9.9.9 "
}
}
}作为一个例子，可以从使用github跟踪您的项目到使用项目JIRA使用postchangelog脚本来替换包含“ https://github.com/” myproject`/issues/'的URL片段，并使用指向JIRA的链接 - 假设您已经安装了替换替换替代品
{
"standard-version" : {
"scripts" : {
"postchangelog" : " replace 'https://github.com/myproject/issues/' 'https://myjira/browse/' CHANGELOG.md "
}
}
}您可以changelog bump以下commit添加到您的软件包：JSON tag
{
"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”
# 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标记采用不同的方法，而无需自动推动（to github）或发布（转到NPM注册表）。 standard-version的使用仅影响您的本地git回购 - 它根本不会影响远程资源。运行standard-version后，您可以查看发布状态，正确的错误并遵循对您的代码库最有意义的发布策略。
我们认为它们都是很棒的工具，我们鼓励人们使用semantic-release而不是standard-version如果它们对他们的用例有意义。
合并拉的请求时，壁板提交的说明假设一个PR最多等于一个功能或修复。
如果您有多个功能或修复单个PR中的降落，并且每个提交都会使用结构化消息，则可以在接受PR时进行标准合并。合并后，这将保留您分支机构的提交历史。
尽管这将允许每个提交作为ChangElog中的单独条目包括在内，但条目将无法参考拉动更改的PR，因为保留的提交消息不包括PR号。
因此，我们建议将每个PR的范围保留到一个一般功能或修复中。在实践中，这使您可以在进行每个小更改时使用非结构化的提交消息，然后将它们挤入一个结构化消息（引用PR编号）后，一旦审查并接受了它们。
standard-version用于其他元数据文件，语言或版本文件吗？从版本7.1.0开始，您可以配置多个bumpFiles和packageFiles 。
bumpFile “ filename ”，这是要“ bump”的文件的途径bumpFile “ updater ”，这就是将文件撞到的方式。一个。如果您使用的是通用类型，则可以通过指定type来使用standard-version的内置updaters之一。 b。如果您使用了一个较不常见的版本文件，则可以创建自己的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
