standard version
v9.5.0
standard-version非推奨です。 GitHubユーザーの場合は、代替手段としてリリースをお勧めします。 GitHubアクションを使用できない場合、または他の理由でstandard-versionに固執する必要がある場合は、standard-versionのコミットアンドタグバージョンフォークを使用できます。
従来のコミットを搭載したSemverとChangelog Generationを使用したバージョン化のユーティリティ。
問題がありますか？貢献したいですか？ノードツールコミュニティのSlackにご参加ください。
それがどのように機能するか：
standard-versionを実行します。 standard-version次のことを行います。
packageFiles [1]を調べて、最後のgit tagに戻ってリポジトリの現在のバージョンを取得します。bumpFiles [1]にバージョンbump 。changelogを生成します（フードの下で従来のチャンゲログを使用します）。bumpFiles [1]と更新されたchangelogを含む新しいcommitを作成します。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-versionインストールnpm runスクリプトとしてインストールしてdevDependenciesに追加します。
npm i --save-dev standard-version
package.jsonにnpm runスクリプトを追加します：
{
"scripts" : {
"release" : " standard-version "
}
}これで、 npm versionの代わりにnpm run releaseを使用できます。
これには、他の開発者がマシンにグローバルにstandard-versionをインストールすることなくリリースを削減できるように、レポ/パッケージをよりポータブルにすることの利点があります。
binとしてグローバルにインストールします（ PATHに追加）：
npm i -g standard-version
これで、 npm versionの代わりにstandard-versionを使用できます。
これには、それぞれに開発者の依存関係を追加せずに、任意のレポ/パッケージでstandard-versionを使用できるようにするという利点があります。
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によって受け入れられたコマンドラインパラメーターは、構成を介して提供できます。利用可能な構成オプションの詳細については、従来のChangelog-Config-Specを参照してください。
デフォルトでは（ 6.0.0の時点で）、 standard-version eventionalcommitsプリセットを使用します。
このプリセット：
Changelogの生成に関連することができるさまざまなダイヤルとノブがあります。
例として、GitHubではなくgitlabを使用しているとしたら、次の変数を変更する場合があります。
commitUrlFormat ：コミットメッセージで検出されたコミットSHAのURL形式。compareUrlFormat ：2つのタグを比較するために使用されるURL形式。issueUrlFormat ：問題にリンクするために使用されるURL形式。これらのURLを作成すると、GithubのものではなくGitlabの形式と一致します。
注：
package.jsonでそれらを定義せずにネストされた構成をCLIに渡すには、パラメーター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-versiongitコミットメッセージが従来の正確である限り、semverタイプを指定する必要はなく、変更された変更を無料で取得できます。 o/
リリースをカットした後、準備ができたら新しいgitタグとnpm publish （またはnpm publish --tag next ）をプッシュできます。
フラグを使用して--prereleaseにプレリリースを生成します。
コードの最後のバージョンが1.0.0であり、コミットされるコードが変更をパッチしたとします。走る：
# npm run script
npm run release -- --prereleaseこれにより、バージョンにタグ付けされます： 1.0.1-0 。
プレリリースに名前を付けたい場合は、by --prerelease <name> by viaという名前を指定します。
たとえば、プレリリースにはalphaプレフィックスが含まれている必要があるとします。
# npm run script
npm run release -- --prerelease alphaこれにより、バージョンのタグ付け： 1.0.1-alpha.0
npm versionのように）自動minorされたバージョンのバンプ使用patch忘れ--release-asくださいmajor
コードの最後のバージョンが1.0.0であると仮定すると、 fix:コミットしますが、次のリリースをminorにしたいと思います。次のことを実行するだけです。
# npm run script
npm run release -- --release-as minor
# Or
npm run release -- --release-as 1.1.0自動生成バージョン1.0.1ではなく、バージョン1.1.0を取得します。
注：
--release-asと--prereleaseを組み合わせてリリースを生成できます。これは、実験機能を公開する場合に役立ちます。
コミット前にコードをテストする前にコードをテストするためにgitフックを使用している場合、 --no-verifyオプションを渡すことで、コミットステップ中にフックが検証されるのを防ぐことができます。
# npm run script
npm run release -- --no-verify
# or global bin
standard-version --no-verifyGPGキーをセットアップしている場合は、 --signまたは-sフラグをstandard-versionコマンドに追加します。
standard-versionライフサイクルスクリプトをサポートしています。これらを使用すると、リリース中に独自の補足コマンドを実行できます。次のフックが利用可能で、文書化された注文で実行されます。
prerelease ：何かが起こる前に実行されます。 prereleaseスクリプトがゼロ以外の出口コードを返す場合、バージョン化は中止されますが、プロセスに他の影響はありません。prebump / postbump ：バージョンがぶつかる前後に実行されます。 prebumpスクリプトがバージョン＃を返す場合、 standard-versionによって計算されたバージョンではなく使用されます。prechangelog / postchangelog ：Changelogが生成される前後に実行されます。precommit / postcommit ：コミットステップの前後に呼び出されます。pretag / posttag ：タグ付けステップの前後に呼び出されます。Package.jsonに次のことを追加するだけで、ライフサイクルスクリプトを構成します。
{
"standard-version" : {
"scripts" : {
"prebump" : " echo 9.9.9 "
}
}
} Githubを使用してアイテムを使用してプロジェクトの使用に変更する例として、Jiraはpostchangelogスクリプトを使用して、「https://github.com/`myproject`/issues/」を含むURLフラグメントを置き換えます。
{
"standard-version" : {
"scripts" : {
"postchangelog" : " replace 'https://github.com/myproject/issues/' 'https://myjira/browse/' CHANGELOG.md "
}
}
}Package.jsonに以下を追加することで、ライフサイクルの手順（ bump 、 changelog 、 commit 、 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 "
}
}フラグを使用し--dry-run standard-versionを実行すると、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フラグを使用して、値として空の文字列を提供できます。
注：simply -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タグ付けを自動プッシュ（GitHubに）または公開（NPMレジストリ）なしで処理することにより、異なるアプローチを取ります。 standard-versionの使用は、ローカルGITレポブにのみ影響します。リモートリソースにはまったく影響しません。 standard-versionを実行した後、リリース状態を確認し、間違いを正しくし、コードベースにとって最も理にかなっているリリース戦略に従うことができます。
私たちはどちらも素晴らしいツールだと思います。また、ユースケースにとって理にかなっている場合はstandard-versionの代わりにsemantic-releaseを使用することを奨励しています。
プルリクエストをマージすると、1つのPRがせいぜい1つの機能または修正が等しいと想定しているときに、コミットをしゃぶすようにする指示はありません。
複数の機能があるか、単一のPRに着陸し、各コミットが構造化されたメッセージを使用している場合、PRを受け入れるときに標準マージを行うことができます。これにより、マージ後の支店からのコミット履歴が保存されます。
これにより、各コミットをChangelogに個別のエントリとして含めることができますが、エントリは、保存されたコミットメッセージにはPR番号が含まれていないため、変更を引くPRを参照することはできません。
このため、各PRの範囲を1つの一般的な機能または修正に保つことをお勧めします。実際には、それぞれの小さな変更をコミットするときに非構造化されたコミットメッセージを使用し、レビューおよび受け入れられたら、構造化されたメッセージ（PR番号を参照）で単一のコミットに押し込んでください。
standard-versionを使用できますか？バージョン7.1.0の時点で、複数のbumpFilesとpackageFilesを構成できます。
bumpFile 「 filename 」を指定します。これは、「bumb」にしたいファイルへのパスですbumpFile 「 updater 」を指定します。これがファイルの衝突方法です。 a。一般的なタイプを使用している場合は、 typeを指定して、 standard-versionの組み込みのupdatersの1つを使用できます。 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 s updater 、少なくとも2つの方法が公開されている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
