standard version
v9.5.0
standard-versionest obsolète . Si vous êtes un utilisateur de GitHub, je recommande la libération de vous-même comme une alternative. Si vous n'êtes pas en mesure d'utiliser des actions GitHub, ou si vous devez vous en tenir àstandard-versionpour une autre raison, vous pouvez utiliser la fourche Commit-and-Tag-Version destandard-version.
Un utilitaire de versioning utilisant Semver et Changelog Génération alimentée par des commits conventionnels.
Vous avez des problèmes? Vous voulez contribuer? Rejoignez-nous sur la communauté de la communauté de réseaux de nœuds .
Comment ça marche:
standard-version . standard-version fera alors ce qui suit:
packageFiles [1], en retombant à la dernière git tag .bump la version dans bumpFiles [1] en fonction de vos validations.changelog basé sur vos commits (utilise le change-changel conventionnel sous le capot).commit comprenant vos bumpFiles [1] et le modificateur mis à jour.tag avec le nouveau numéro de version.bumpFiles , packageFiles et updaters standard-version utilise quelques concepts clés pour gérer la version de la version dans votre projet.
packageFiles - Fichiers définis par l'utilisateur où les versions peuvent être lues et être "heurtées".package.json , manifest.jsonpackageFiles sont un sous-ensemble de bumpFiles .bumpFiles - Fichiers définis par l'utilisateur où les versions doivent être "heurtées", mais pas explicitement lues.package-lock.json , npm-shrinkwrap.jsonupdaters - modules simples utilisés pour lire packageFiles et écrire sur bumpFiles . Par défaut, standard-version suppose que vous travaillez dans un projet basé sur NodeJS ... Pour cette raison, pour la majorité des projets, vous n'aurez peut-être jamais besoin d'interagir avec ces options.
Cela dit, si vous trouvez votre auto pour vous demander comment puis-je utiliser la version standard pour des fichiers de métadonnées, des langues ou des fichiers de version supplémentaires? - Ces options de configuration vous aideront!
standard-versionnpm run local Installer et ajouter aux devDependencies :
npm i --save-dev standard-version
Ajoutez un script npm run à votre package.json :
{
"scripts" : {
"release" : " standard-version "
}
} Vous pouvez maintenant utiliser npm run release à la place de npm version .
Cela a l'avantage de rendre votre repo / package plus portable, afin que d'autres développeurs puissent couper des versions sans avoir à installer globalement standard-version sur leur machine.
bin mondial Installer à l'échelle mondiale (ajouter à votre PATH ):
npm i -g standard-version
Vous pouvez maintenant utiliser standard-version à la place de npm version .
Cela a l'avantage de vous permettre d'utiliser standard-version sur n'importe quel réapprovisionnement / package sans ajouter de dépendance de développement à chacun.
npx À partir de [email protected] , npx est installé aux côtés de npm . En utilisant npx vous pouvez utiliser standard-version sans avoir à conserver un fichier package.json en exécutant: npx standard-version .
Cette méthode est particulièrement utile lors de l'utilisation standard-version dans des projets non javascript.
Vous pouvez configurer standard-version soit par:
standard-version dans votre package.json (en supposant que votre projet est javascript)..versionrc , .versionrc.json ou .versionrc.js ..versionrc.js votre exportation par défaut doit être un objet de configuration ou une fonction renvoyant un objet de configuration. Tous les paramètres de ligne de commande acceptés par standard-version peuvent plutôt être fournis via la configuration. Veuillez vous référer à la conventionnelle-changelog-config-Spec pour plus de détails sur les options de configuration disponibles.
Par défaut (en 6.0.0 ), standard-version utilise le préréglage ConventionalComts.
Ce préréglage:
Il existe une variété de cadrans et de boutons que vous pouvez tourner liés à la génération de changelog.
À titre d'exemple, supposons que vous utilisiez GitLab, plutôt que GitHub, vous pouvez modifier les variables suivantes:
commitUrlFormat : Le format URL de Commit Shas détecté dans les messages de validation.compareUrlFormat : le format URL utilisé pour comparer deux balises.issueUrlFormat : Le format URL utilisé pour être lié aux problèmes.Faire ces URL correspondent au format de Gitlab, plutôt que celui de GitHub.
Remarque: Pour passer les configurations imbriquées à la CLI sans les définir dans le
package.jsonUtilisez la notation DOT comme paramètreseg --skip.changelog.
Pour générer votre changelog pour votre première version, faites simplement:
# npm run script
npm run release -- --first-release
# global bin
standard-version --first-release
# npx
npx standard-version --first-release Cela marquera une version sans heurter la version bumpFiles 1 .
Lorsque vous êtes prêt, poussez la balise GIT et npm publish votre première version. o /
Si vous utilisez généralement npm version pour couper une nouvelle version, faites-le à la place:
# npm run script
npm run release
# or global bin
standard-versionTant que vos messages Git Commit sont conventionnels et précis, vous n'avez plus besoin de spécifier le type SEMVER - et vous obtenez une génération de changelog gratuitement! o /
Après avoir coupé une version, vous pouvez pousser le nouveau Git Tag et npm publish (ou npm publish --tag next ) lorsque vous êtes prêt.
Utilisez le drapeau --prerelease pour générer des pré-sorties:
Supposons que la dernière version de votre code soit 1.0.0 , et que votre code à engager a des modifications corrigées. Courir:
# npm run script
npm run release -- --prerelease Cela marquera votre version comme suit: 1.0.1-0 .
Si vous souhaitez nommer la pré-version, vous spécifiez le nom via --prerelease <name> .
Par exemple, supposons que votre pré-libération doit contenir le préfixe alpha :
# npm run script
npm run release -- --prerelease alpha Cela marquera la version comme: 1.0.1-alpha.0
npm version -like) Pour renoncer à l'utilisation automatisée de la version de la version --release-as avec l'argument major , minor ou patch .
Supposons que la dernière version de votre code soit 1.0.0 , vous avez seulement atterri fix: Commits, mais vous aimeriez que votre prochaine version soit minor . Exécutez simplement ce qui suit:
# npm run script
npm run release -- --release-as minor
# Or
npm run release -- --release-as 1.1.0 Vous obtiendrez la version 1.1.0 plutôt que ce qui serait la version 1.0.1 générée automatiquement.
Remarque: vous pouvez combiner
--release-aset--prereleasepour générer une version. Ceci est utile lors de la publication des fonctionnalités expérimentales.
Si vous utilisez des crochets Git, comme le pré-engagement, pour tester votre code avant de vous engager, vous pouvez empêcher les crochets d'être vérifiés pendant l'étape de validation en passant l'option --no-verify :
# npm run script
npm run release -- --no-verify
# or global bin
standard-version --no-verify Si vous avez configuré votre clé GPG, ajoutez l'indicateur --sign ou -s à votre commande standard-version .
standard-version prend en charge les scripts de cycle de vie. Ceux-ci vous permettent d'exécuter vos propres commandes supplémentaires pendant la version. Les crochets suivants sont disponibles et s'exécutent dans la commande documentée:
prerelease : exécuté avant que tout se passe. Si le script prerelease renvoie un code de sortie non nul, le versioning sera interdit, mais il n'a aucun autre effet sur le processus.prebump / postbump : exécuté avant et après la version de la version. Si le script prebump renvoie une version #, il sera utilisé plutôt que la version calculée par standard-version .prechangelog / postchangelog : exécute avant et après la génération du changelog.precommit / postcommit : appelé avant et après l'étape de validation.pretag / posttag : appelé avant et après l'étape de marquage.Ajoutez simplement ce qui suit à votre package.json pour configurer les scripts de cycle de vie:
{
"standard-version" : {
"scripts" : {
"prebump" : " echo 9.9.9 "
}
}
} À titre d'exemple pour passer de l'utilisation de GitHub pour suivre vos éléments à l'utilisation de vos projets JIRA Utilisez un script postchangelog pour remplacer le fragment URL contenant 'https://github.com/`myproject`/issues/' par un lien vers votre jira - en supposant que vous avez déjà installé Remplace
{
"standard-version" : {
"scripts" : {
"postchangelog" : " replace 'https://github.com/myproject/issues/' 'https://myjira/browse/' CHANGELOG.md "
}
}
} Vous pouvez ignorer l'une des étapes du cycle de vie ( bump , changelog , commit , tag ), en ajoutant ce qui suit à votre package.json:
{
"standard-version" : {
"skip" : {
"changelog" : true
}
}
} Si vous souhaitez engager des artefacts générés dans le commit de version, vous pouvez utiliser le Flag --commit-all OU -a . Vous devrez mettre en scène les artefacts que vous souhaitez commettre, afin que votre commande release puisse ressembler à ceci:
{
"standard-version" : {
"scripts" : {
"prerelease" : " webpack -p --bail && git add <file(s) to commit> "
}
}
}{
"scripts" : {
"release" : " standard-version -a "
}
} L'exécution standard-version avec le drapeau --dry-run vous permet de voir quelles commandes seraient exécutées, sans vous engager à Git ou à mettre à jour des fichiers.
# npm run script
npm run release -- --dry-run
# or global bin
standard-version --dry-run Les balises sont préfixées par v par défaut. Si vous souhaitez préfixer vos balises avec autre chose, vous pouvez le faire avec l'indicateur -t .
standard-version -t @scope/package @ Cela préfixera vos balises pour ressembler à quelque chose comme @scope/[email protected]
Si vous ne voulez pas avoir de préfixe de balise, vous pouvez utiliser l'indicateur -t et lui fournir une chaîne vide comme valeur.
Remarque: Simply -T ou --Tag-Prefix sans aucune valeur se rendront par défaut «V» par défaut
# 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 } ` )
} ) CONSEIL: Utilisez l'option silent pour empêcher standard-version d'imprimer à la console .
standard-version elle différente de semantic-release ? semantic-release est décrite comme:
SEMANT-Release automatise l'ensemble du flux de travail de version du package, y compris: déterminer le numéro de version suivant, générer les notes de version et publier le package.
Bien que les deux soient basés sur les mêmes fondements de messages de validation structurés, standard-version adopte une approche différente en gérant le versioning, la génération de modifications modifiées et le tagging Git sans poussée automatique (vers Github) ou publication (vers un registre NPM). L'utilisation de standard-version n'affecte que votre dépôt GIT local - il n'affecte pas du tout les ressources à distance. Après avoir exécuté standard-version , vous pouvez consulter votre état de publication, corriger les erreurs et suivre la stratégie de publication qui est le plus logique pour votre base de code.
Nous pensons que ce sont tous deux des outils fantastiques, et nous encourageons les gens à utiliser semantic-release au lieu de standard-version si cela a du sens pour leur cas d'utilisation.
Les instructions pour écraser les engagements lors de la fusion des demandes de traction suppose qu'un PR est égal, au plus, une fonction ou une correction .
Si vous avez plusieurs fonctionnalités ou correcte l'atterrissage dans un seul PR et que chaque engagement utilise un message structuré, vous pouvez faire une fusion standard lorsque vous acceptez le PR. Cela préservera l'historique des engagements de votre succursale après la fusion.
Bien que cela permettra à chaque engagement d'être inclus en tant qu'amis séparés dans votre modification, les entrées ne pourront pas référencer le RP qui a tiré les modifications car les messages de validation préservés n'incluent pas le numéro de relations publiques.
Pour cette raison, nous vous recommandons de garder la portée de chaque PR à une fonction générale ou une correction. En pratique, cela vous permet d'utiliser des messages de validation non structurés lors de la validation de chaque petit changement, puis de les écraser en un seul engagement avec un message structuré (faisant référence au numéro de relations publiques) une fois qu'ils ont été examinés et acceptés.
standard-version pour des fichiers de métadonnées supplémentaires, des langues ou des fichiers de version? À partir de la version 7.1.0 , vous pouvez configurer plusieurs bumpFiles et packageFiles .
filename bumpFile personnalisé ", il s'agit du chemin du fichier que vous souhaitez" bosse "updater " bumpFile , c'est ainsi que le fichier sera heurté. un. Si vous utilisez un type commun, vous pouvez utiliser l'un des updaters intégrés de standard-version en spécifiant un type . né Si vous utilisez un fichier de version moins commun, vous pouvez créer votre propre 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"
}
]
} Si vous utilisez .versionrc.js comme fichier de configuration, le updater peut également être défini comme un objet plutôt que comme un chemin:
// .versionrc.js
const tracker = {
filename : 'VERSION_TRACKER.json' ,
updater : require ( './path/to/custom-version-updater' )
}
module . exports = {
bumpFiles : [ tracker ] ,
packageFiles : [ tracker ]
} updater personnalisée S Un updater devrait être un module JavaScript avec au moins deux méthodes exposées: readVersion et writeVersion .
readVersion(contents = string): stringCette méthode est utilisée pour lire la version à partir du contenu du fichier fourni.
La valeur de retour devrait être une chaîne de version sémantique.
writeVersion(contents = string, version: string): stringCette méthode est utilisée pour écrire la version sur le contenu fourni.
La valeur de retour sera écrite directement (écraser) dans le fichier fourni.
Supposons que notre VERSION_TRACKER.json ait le contenu suivant:
{
"tracker" : {
"package" : {
"version" : " 1.0.0 "
}
}
}
Une standard-version-updater.js acceptable.js serait:
// 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
