standard version
v9.5.0
standard-versionist veraltet . Wenn Sie ein GitHub-Benutzer sind, empfehle ich Release-Bitte als Alternative. Wenn Sie keine GitHub-Aktionen verwenden oder aus einem anderen Grund beistandard-versionbleiben müssen, können Sie die Commit-and-Tag-Tag-Version-Gabel vonstandard-versionverwenden.
Ein Versorgungsunternehmen für die Versionierung mit Semver und ChangeLog Generation, die von herkömmlichen Commits betrieben wird.
Probleme haben? Willst du einen Beitrag leisten? Begleiten Sie uns auf der Node-Tooling Community Slack .
Wie es funktioniert:
standard-version aus. Die standard-version erfolgt dann Folgendes:
packageFiles [1] ansehen und auf das letzte git tag zurückgreifen.bump die Version in bumpFiles [1] basierend auf Ihren Commits.changelog der auf Ihren Commits basiert (verwendet konventionelle Changelog unter der Motorhaube).commit , einschließlich Ihrer bumpFiles [1] und aktualisiertes ChangeLog.tag mit der neuen Versionsnummer.bumpFiles , packageFiles und updaters standard-version verwendet einige Schlüsselkonzepte für die Behandlung von Versionen in Ihrem Projekt.
packageFiles -Benutzerdefinierte Dateien, in denen Versionen gelesen werden können und "gestoßen" werden.package.json , manifest.jsonpackageFiles eine Teilmenge von bumpFiles .bumpFiles -Benutzerdefinierte Dateien, in denen Versionen "gestoppt" werden sollten, aber nicht explizit ausgelesen werden.package-lock.json , npm-shrinkwrap.jsonupdaters - Einfache Module, die zum Lesen packageFiles und zum Schreiben in bumpFiles verwendet werden. Standardmäßig geht standard-version davon aus, dass Sie in einem von NodeJS basierenden Projekt arbeiten. Aus diesem Grund müssen Sie für die meisten Projekte möglicherweise nie mit diesen Optionen interagieren.
Wenn Sie sich selbst fragen, wie kann ich Standardversion für zusätzliche Metadatendateien, Sprachen oder Versionsdateien verwenden? - Diese Konfigurationsoptionen helfen!
standard-versionnpm run Installieren und zu devDependencies hinzufügen:
npm i --save-dev standard-version
Fügen Sie Ihrem package.json ein npm run -Skript hinzu. Json:
{
"scripts" : {
"release" : " standard-version "
}
} Jetzt können Sie npm run release anstelle der npm version verwenden.
Dies hat den Vorteil, dass Ihr Repo/Paket tragbarer wird, damit andere Entwickler die Veröffentlichungen kürzen können, ohne standard-version auf ihrem Computer global installieren zu müssen.
bin Global installieren (zu Ihrem PATH hinzufügen):
npm i -g standard-version
Jetzt können Sie standard-version anstelle der npm version verwenden.
Dies hat den Vorteil, dass Sie standard-version in jedem Repo/Paket verwenden können, ohne dass Sie jeder einzelnen eine Dev-Abhängigkeit hinzufügen können.
npx Ab [email protected] wird npx neben npm installiert. Mit npx können Sie standard-version verwenden, ohne eine package.json Datei durch auszuführen: npx standard-version .
Diese Methode ist besonders nützlich, wenn standard-version in Nicht-JavaScript-Projekten verwendet wird.
Sie können standard-version entweder konfigurieren nach:
standard-version -Strophe in Ihr package.json (vorausgesetzt, Ihr Projekt ist JavaScript)..versionrc , .versionrc.json oder .versionrc.js ..versionrc.js verwenden, muss Ihr Standard -Export ein Konfigurationsobjekt oder eine Funktion sein, die ein Konfigurationsobjekt zurückgibt. Eine der durch standard-version akzeptierten Befehlszeilenparameter kann stattdessen über die Konfiguration bereitgestellt werden. Weitere Informationen zu verfügbaren Konfigurationsoptionen finden Sie im konventionellen Changelog-Config-Spec.
Standardmäßig (ab 6.0.0 ) verwendet standard-version die konventionellen Voreinstellung.
Diese Voreinstellung:
Es gibt eine Vielzahl von Zifferblättern und Knöpfen, die Sie mit der ChangeLog -Generierung in Verbindung bringen können.
Angenommen, Sie verwenden GitLab und nicht GitHub, können Sie die folgenden Variablen ändern:
commitUrlFormat : Das URL -Format von Commit -Shas, die in Commit -Nachrichten erkannt wurden.compareUrlFormat : Das URL -Format zum Vergleich von zwei Tags.issueUrlFormat : Das URL -Format, das zur Verbindung zu Problemen verwendet wird.Wenn diese URLs nicht mit dem Format von Gitlab übereinstimmen, anstatt Githubs.
Hinweis: Um verschachtelte Konfigurationen an die CLI weiterzugeben
eg --skip.changelogohne sie impackage.jsonzu definieren.
Um Ihren Changelog für Ihre erste Veröffentlichung zu generieren, tun Sie einfach:
# npm run script
npm run release -- --first-release
# global bin
standard-version --first-release
# npx
npx standard-version --first-release Dadurch wird eine Version markiert , ohne die Versions bumpFiles 1 zu erhöhen .
Wenn Sie bereit sind, npm publish Ihre erste Version. O/
Wenn Sie normalerweise npm version verwenden, um eine neue Version zu verkürzen, tun Sie dies stattdessen:
# npm run script
npm run release
# or global bin
standard-versionSolange Ihre Git -Commit -Nachrichten konventionell und genau sind, müssen Sie den Semver -Typ nicht mehr angeben - und Sie erhalten die ChangeLog -Generation kostenlos! O/
Nachdem Sie eine Veröffentlichung geschnitten haben, können Sie das neue GIT -Tag und npm publish (oder npm publish --tag next ), wenn Sie bereit sind.
Verwenden Sie das Flag --prerelease , um Vorabversionen zu generieren:
Angenommen, die letzte Version Ihres Codes ist 1.0.0 , und Ihr zu begangenes Code hat Änderungen gepatcht. Laufen:
# npm run script
npm run release -- --prerelease Dadurch wird Ihre Version als: 1.0.1-0 gekennzeichnet.
Wenn Sie die Vorabveröffentlichung benennen möchten, geben Sie den Namen über --prerelease <name> an.
Nehmen wir beispielsweise an, Ihre Vorabveröffentlichung sollte das alpha Präfix enthalten:
# npm run script
npm run release -- --prerelease alpha Dadurch wird die Version als: 1.0.1-alpha.0 gekennzeichnet
npm version -LICH) Auf die Verwendung der automatisierten Version der Version --release-as das Argument major , minor oder patch .
Angenommen, die letzte Version Ihres Codes ist 1.0.0 , Sie haben nur fix: Commits gelandet, aber Sie möchten, dass Ihre nächste Veröffentlichung ein minor ist. Führen Sie einfach Folgendes aus:
# npm run script
npm run release -- --release-as minor
# Or
npm run release -- --release-as 1.1.0 Sie erhalten Version 1.1.0 und nicht die automatische Version 1.0.1 .
HINWEIS: Sie können
--release-asund--prereleaseum eine Veröffentlichung zu generieren. Dies ist nützlich, wenn experimentelle Funktionen veröffentlichen.
Wenn Sie Git-Hooks wie Pre-Commit verwenden, um Ihren Code vor dem Verhalten zu testen, können Sie verhindern, dass Hooks während des Festschreibungschritts überprüft werden, indem Sie die Option --no-verify -Option übergeben:
# npm run script
npm run release -- --no-verify
# or global bin
standard-version --no-verify Wenn Sie Ihr GPG -Schlüssel einrichten lassen, fügen Sie das Flag --sign oder -s -Flag zu Ihrem Befehl standard-version hinzu.
standard-version unterstützt Lebenszyklusskripte. Mit diesen können Sie während der Veröffentlichung Ihre eigenen Zusatzbefehle ausführen. Die folgenden Haken sind verfügbar und werden in der dokumentierten Reihenfolge ausgeführt:
prerelease : Vor dem passiert, bevor irgendetwas passiert. Wenn das prerelease -Skript einen Exit-Code ungleich Null zurückgibt, wird die Versionierung abgebrochen, hat jedoch keinen anderen Effekt auf den Prozess.prebump / postbump : Vorher und nach der Version der Version ausgeführt. Wenn das prebump -Skript eine Version #zurückgibt, wird es eher verwendet als die Version, die durch standard-version berechnet wird.prechangelog / postchangelog : führt vor und nach dem Erstellen des Changelogs aus.precommit / postcommit : Vor und nach dem Festungsschritt gerufen.pretag / posttag : Vor und nach dem Tagging -Schritt angerufen.Fügen Sie einfach Folgendes zu Ihrem Paket hinzu.json, um Lebenszyklusskripte zu konfigurieren:
{
"standard-version" : {
"scripts" : {
"prebump" : " echo 9.9.9 "
}
}
} Als Beispiel für die Änderung von Github zum Verfolgen Ihrer Elemente zur Verwendung Ihrer Projekte. JIRA verwenden ein postchangelog -Skript, um das URL
{
"standard-version" : {
"scripts" : {
"postchangelog" : " replace 'https://github.com/myproject/issues/' 'https://myjira/browse/' CHANGELOG.md "
}
}
} Sie können einen der Lebenszyklusschritte überspringen ( bump , changelog , commit , tag ), indem Sie Ihr Paket zu Ihrem Paket hinzufügen. JSON:
{
"standard-version" : {
"skip" : {
"changelog" : true
}
}
} Wenn Sie im Release -Commit generierte Artefakte begehen möchten, können Sie die Flagge --commit-all oder -a -Flaggen verwenden. Sie müssen die Artefakte, die Sie begehen möchten, inszenieren, damit Ihr release so aussehen könnte:
{
"standard-version" : {
"scripts" : {
"prerelease" : " webpack -p --bail && git add <file(s) to commit> "
}
}
}{
"scripts" : {
"release" : " standard-version -a "
}
} Durch Ausführen von standard-version mit dem Flag --dry-run ermöglicht es Ihnen, zu sehen, welche Befehle ausgeführt werden würden, ohne sich auf Git- oder Aktualisierungsdateien zu verpflichten.
# npm run script
npm run release -- --dry-run
# or global bin
standard-version --dry-run Tags werden standardmäßig mit v vorangestellt. Wenn Sie Ihre Tags mit etwas anderem Präfix möchten, können Sie dies mit dem -t -Flag tun.
standard-version -t @scope/package @ Dadurch wird Ihre Tags vorangestellt, um so etwas wie @scope/[email protected] auszusehen
Wenn Sie kein Tag -Präfix haben möchten, können Sie das Flag -t verwenden und es mit einer leeren Zeichenfolge als Wert angeben.
HINWEIS: Einfach -t oder - -Tag -Prefix ohne Wert fällt in den Standard 'V' zurück
# 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 } ` )
} ) Tipp: Verwenden Sie die silent Option, um zu verhindern, dass standard-version in die console druckt.
standard-version von semantic-release ? semantic-release wird beschrieben als:
Semantic-Release automatisiert den gesamten Paket-Release-Workflow, einschließlich: Ermittlung der nächsten Versionsnummer, Erzeugen der Versionshinweise und Veröffentlichung des Pakets.
Während beide auf der gleichen Grundlage strukturierter Festschreibungsnachrichten basieren, verfolgt standard-version einen anderen Ansatz, indem Sie Versioning, ChangeLog-Generierung und Git-Tagging für Sie bearbeiten, ohne automatisch zu pushen (zu Github) oder zu veröffentlichen (zu einer NPM-Registrierung). Die Verwendung von standard-version wirkt sich nur auf Ihr lokales Git -Repo aus - sie wirkt sich überhaupt nicht auf Remote -Ressourcen aus. Nachdem Sie standard-version ausgeführt haben, können Sie Ihren Release-Status überprüfen, Fehler korrigieren und die Release-Strategie befolgen, die für Ihre Codebasis am sinnvollsten ist.
Wir denken, dass sie beide fantastische Werkzeuge sind, und wir ermutigen die Leute, semantic-release anstelle von standard-version zu verwenden, wenn es für ihren Anwendungsfall sinnvoll ist.
Die Anweisungen für Squash -Commits bei der Verschmelzung von Pull -Anfragen gehen davon aus, dass ein PR höchstens eine Funktion oder ein Problem entspricht .
Wenn Sie über mehrere Funktionen oder Behebungsstörungen in einer einzelnen PR verfügen und jedes Commit eine strukturierte Nachricht verwendet, können Sie beim Akzeptieren der PR eine Standardverführung durchführen. Dadurch erhalten Sie nach der Zusammenführung die Ausschreibung Geschichte von Ihrem Zweig.
Dies ermöglicht es jedoch, dass jeder Commit als separate Einträge in Ihrem ChangeLog aufgenommen wird, aber die Einträge können nicht auf die PR verweisen, die die Änderungen angerufen hat, da die erhaltenen Festschreibungsmeldungen die PR -Nummer nicht enthalten.
Aus diesem Grund empfehlen wir, den Umfang jeder PR auf eine allgemeine Funktion oder ein allgemeiner Feature zu halten. In der Praxis können Sie unstrukturierte Festungsnachrichten verwenden, wenn Sie jede kleine Änderung begehen und sie dann in ein einzelnes Commit mit einer strukturierten Nachricht (Verweis auf die PR -Nummer), sobald sie überprüft und akzeptiert wurden.
standard-version für zusätzliche Metadatendateien, Sprachen oder Versionsdateien verwenden? Ab Version 7.1.0 können Sie mehrere bumpFiles und packageFiles konfigurieren.
bumpFile " filename " an. Dies ist der Pfad zu der Datei, die Sie "stoßen" möchten.bumpFile " updater " an, so wird die Datei gestoßen. A. Wenn Sie einen gemeinsamen Typ verwenden, können Sie einen der integrierten updaters von standard-version verwenden, indem Sie einen type angeben. B. Wenn Sie eine Version von weniger gewinnbringlich verwenden, können Sie Ihren eigenen updater erstellen. // .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"
}
]
} Bei Verwendung .versionrc.js als Konfigurationsdatei kann der updater auch als Objekt anstelle eines Pfades festgelegt werden:
// .versionrc.js
const tracker = {
filename : 'VERSION_TRACKER.json' ,
updater : require ( './path/to/custom-version-updater' )
}
module . exports = {
bumpFiles : [ tracker ] ,
packageFiles : [ tracker ]
} updater s Es wird erwartet, dass ein updater ein JavaScript -Modul mit mindestens zwei Methoden ist: readVersion und writeVersion .
readVersion(contents = string): stringDiese Methode wird verwendet, um die Version aus dem angegebenen Dateiinhalt zu lesen.
Der Rückgabewert wird voraussichtlich eine semantische Versionszeichenfolge sein.
writeVersion(contents = string, version: string): stringDiese Methode wird verwendet, um die Version in den bereitgestellten Inhalt zu schreiben.
Der Rückgabewert wird direkt (überschreiben) in die angegebene Datei geschrieben.
Nehmen wir an, unsere VERSION_TRACKER.json hat den folgenden Inhalt:
{
"tracker" : {
"package" : {
"version" : " 1.0.0 "
}
}
}
Ein akzeptabler standard-version-updater.js wäre:
// 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
