standard version
v9.5.0
standard-versionestá en desuso . Si eres un usuario de GitHub, le recomiendo a la liberación de la placa como una alternativa. Si no puede usar acciones de GitHub, o si necesita seguir constandard-versionpor alguna otra razón, puede usar la horquilla de comprensión de confirmación y etiqueta destandard-version.
Una utilidad para versiones utilizando Semver y ChangeLog Generation alimentada por comodidades convencionales.
¿Tiene problemas? ¿Quieres contribuir? Únase a nosotros en la comunidad de la comunidad de remolinos de nodo .
Cómo funciona:
standard-version . standard-version hará lo siguiente:
packageFiles [1], volviendo a la última git tag .bump la versión en bumpFiles [1] según tus compromisos.changelog basado en sus compromisos (utiliza el Changelog convencional debajo del capó).commit que incluye sus bumpFiles [1] y ChangeLog actualizado.tag con el nuevo número de versión.bumpFiles , packageFiles y updaters standard-version utiliza algunos conceptos clave para manejar el aumento de la versión en su proyecto.
packageFiles : archivos definidos por el usuario donde las versiones se pueden leer y ser "superadas".package.json , manifest.jsonpackageFiles son un subconjunto de bumpFiles .bumpFiles : archivos definidos por el usuario donde las versiones deben ser "superadas", pero no se leen explícitamente.package-lock.json , npm-shrinkwrap.jsonupdaters : módulos simples utilizados para leer packageFiles y escribir a bumpFiles . Por defecto, standard-version supone que está trabajando en un proyecto basado en NodeJS ... Debido a esto, para la mayoría de los proyectos, es posible que nunca necesite interactuar con estas opciones.
Dicho esto, si se encuentra a sí mismo, ¿cómo puedo usar la versión estándar para archivos de metadatos adicionales, idiomas o archivos de versión? - ¡Estas opciones de configuración ayudarán!
standard-versionnpm run local Instalar y agregar a devDependencies :
npm i --save-dev standard-version
Agregue un script npm run a su package.json :
{
"scripts" : {
"release" : " standard-version "
}
} Ahora puede usar npm run release en lugar de npm version .
Esto tiene el beneficio de hacer que su repositorio/paquete sea más portátil, para que otros desarrolladores puedan reducir las versiones sin tener que instalar globalmente standard-version en su máquina.
bin global Instale globalmente (agregue a su PATH ):
npm i -g standard-version
Ahora puede usar standard-version en lugar de npm version .
Esto tiene el beneficio de permitirle usar standard-version en cualquier repositorio/paquete sin agregar una dependencia de desarrollo a cada uno.
npx A partir de [email protected] , npx se instala junto con npm . Uso de npx puede usar standard-version sin tener que mantener un archivo package.json ejecutando: npx standard-version .
Este método es especialmente útil cuando se usa standard-version en proyectos que no son JavaScript.
Puede configurar standard-version ya sea por:
standard-version en su package.json (suponiendo que su proyecto sea JavaScript)..versionrc , .versionrc.json o .versionrc.js ..versionrc.js su exportación predeterminada debe ser un objeto de configuración o una función que devuelva un objeto de configuración. En cambio, cualquiera de los parámetros de línea de comando aceptados por standard-version se puede proporcionar a través de la configuración. Consulte el Spec convencional-Changelog-Config para obtener detalles sobre las opciones de configuración disponibles.
Por defecto (a partir de 6.0.0 ), standard-version utiliza el preajuste de ConvencionalCommits.
Este preajuste:
Hay una variedad de diales y perillas que puede poner relacionadas con la generación de ChangeLog.
Como ejemplo, suponga que está utilizando GitLab, en lugar de GitHub, puede modificar las siguientes variables:
commitUrlFormat : el formato de URL de Commit SHAS detectado en mensajes de confirmación.compareUrlFormat : el formato URL utilizado para comparar dos etiquetas.issueUrlFormat : el formato URL utilizado para vincular a los problemas.Hacer estas URL coinciden con el formato de Gitlab, en lugar de el de Github.
Nota: Pasar configuraciones anidadas al CLI sin definirlas en el
package.jsonJSON Use la notación de puntos como parámetroseg --skip.changelog.
Para generar su CangeLog para su primer lanzamiento, simplemente haga:
# npm run script
npm run release -- --first-release
# global bin
standard-version --first-release
# npx
npx standard-version --first-release Esto etiquetará un lanzamiento sin golpear la versión bumpFiles 1 .
Cuando esté listo, presione la etiqueta GIT y npm publish su primera versión. o/
Si normalmente usa npm version para cortar una nueva versión, haga esto en su lugar:
# npm run script
npm run release
# or global bin
standard-versionMientras sus mensajes de confirmación GIT sean convencionales y precisos, ya no necesita especificar el tipo Semver, ¡y obtiene la generación de ChangeLog de forma gratuita! o/
Después de cortar un lanzamiento, puede presionar la nueva etiqueta GIT y npm publish (o npm publish --tag next ) cuando esté listo.
Use la bandera --prerelease para generar prensados:
Supongamos que la última versión de su código es 1.0.0 , y su código a comprometerse tiene cambios parcheados. Correr:
# npm run script
npm run release -- --prerelease Esto etiquetará su versión como: 1.0.1-0 .
Si desea nombrar el prelanzamiento, especifica el nombre a través de --prerelease <name> .
Por ejemplo, suponga que su prelanzamiento debe contener el prefijo alpha :
# npm run script
npm run release -- --prerelease alpha Esto etiquetará la versión como: 1.0.1-alpha.0
npm version ) Para renunciar al uso de la versión automatizada --release-as con el argumento major , minor o patch .
Supongamos que la última versión de su código es 1.0.0 , solo ha conseguido fix: Compromisos, pero desea que su próxima versión sea un minor . Simplemente ejecute lo siguiente:
# npm run script
npm run release -- --release-as minor
# Or
npm run release -- --release-as 1.1.0 Obtendrá la versión 1.1.0 en lugar de lo que sería la versión 1.0.1 generada automáticamente.
Nota: Puede combinar
--release-asy--prereleasepara generar una versión. Esto es útil al publicar características experimentales.
Si usa gits Git, como el pre-Commit, para probar su código antes de comprometerse, puede evitar que los ganchos se verifiquen durante el paso de confirmación al pasar la opción --no-verify :
# npm run script
npm run release -- --no-verify
# or global bin
standard-version --no-verify Si tiene configurado su tecla GPG, agregue el indicador --sign o -s a su comando standard-version .
standard-version admite scripts de ciclo de vida. Estos le permiten ejecutar sus propios comandos complementarios durante el lanzamiento. Los siguientes ganchos están disponibles y ejecutan en el orden documentado:
prerelease : ejecutado antes de que algo suceda. Si el script prerelease devuelve un código de salida no distinto de cero, el versiones se abortará, pero no tiene otro efecto en el proceso.prebump / postbump : ejecutado antes y después de que se tope la versión. Si el script prebump devuelve una versión #, se utilizará en lugar de la versión calculada por standard-version .prechangelog / postchangelog : se ejecuta antes y después de que se genera ChangeLog.precommit / postcommit : llamado antes y después del paso de confirmación.pretag / posttag : llamado antes y después del paso de etiquetado.Simplemente agregue lo siguiente a su paquete.json para configurar los scripts de ciclo de vida:
{
"standard-version" : {
"scripts" : {
"prebump" : " echo 9.9.9 "
}
}
} Como ejemplo, cambiar de usar GitHub para rastrear sus elementos a usar sus proyectos JIRA Use un script postchangelog para reemplazar el fragmento de URL que contiene 'https://github.com/`myproject`/issues/' con un enlace a su jira, suponiendo que haya instalado reemplazo
{
"standard-version" : {
"scripts" : {
"postchangelog" : " replace 'https://github.com/myproject/issues/' 'https://myjira/browse/' CHANGELOG.md "
}
}
} Puede omitir cualquiera de los pasos del ciclo de vida ( bump , changelog , commit , tag ), agregando lo siguiente a su paquete.json:
{
"standard-version" : {
"skip" : {
"changelog" : true
}
}
} Si desea comprometer artefactos generados en la confirmación de lanzamiento, puede usar el indicador --commit-all o -a . Deberá organizar los artefactos que desea cometer, para que su comando release pueda verse así:
{
"standard-version" : {
"scripts" : {
"prerelease" : " webpack -p --bail && git add <file(s) to commit> "
}
}
}{
"scripts" : {
"release" : " standard-version -a "
}
} Ejecución standard-version con el indicador --dry-run le permite ver qué comandos se ejecutarían, sin comprometerse a git o actualizar archivos.
# npm run script
npm run release -- --dry-run
# or global bin
standard-version --dry-run Las etiquetas tienen el prefijo v por defecto. Si desea prefijo sus etiquetas con algo más, puede hacerlo con la bandera -t .
standard-version -t @scope/package @ Esto prefijo sus etiquetas para que se vea como @scope/[email protected]
Si no desea tener ningún prefijo de etiqueta, puede usar el indicador -t y proporcionarle una cadena vacía como valor.
Nota: simplemente -t o -tag -prefix sin ningún valor se retrasará en el 'v' predeterminado
# 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 } ` )
} ) Consejo: use la opción silent para evitar que standard-version imprima a la console .
standard-version de semantic-release ? semantic-release se describe como:
La liberación semántica automatiza todo el flujo de trabajo de lanzamiento del paquete que incluye: Determinar el próximo número de versión, generar las notas de versión y publicar el paquete.
Si bien ambos se basan en la misma base de mensajes de confirmación estructurada, standard-version adopta un enfoque diferente al manejar el versiones, la generación de cambios de cambio y el etiquetado GIT para usted sin empuje automático (a GitHub) o publicando (a un registro NPM). El uso de standard-version solo afecta su repositorio Git local: no afecta en absoluto los recursos remotos. Después de ejecutar standard-version , puede revisar su estado de lanzamiento, corregir errores y seguir la estrategia de lanzamiento que tenga más sentido para su base de código.
Creemos que ambas son herramientas fantásticas, y alentamos a las personas a usar semantic-release en lugar de standard-version si tiene sentido para su caso de uso.
Las instrucciones para aplicar comodidades al fusionar solicitudes de extracción suponen que un PR equivale, como máximo, una característica o solución .
Si tiene múltiples características o correcciones de aterrizaje en un solo PR y cada confirmación usa un mensaje estructurado, entonces puede hacer una fusión estándar al aceptar el PR. Esto preservará el historial de confirmación de su rama después de la fusión.
Aunque esto permitirá que cada compromiso se incluya como entradas separadas en su CangeLog, las entradas no podrán hacer referencia al PR que extrajo los cambios porque los mensajes de confirmación preservados no incluyen el número de PR.
Por esta razón, recomendamos mantener el alcance de cada PR a una característica general o una solución. En la práctica, esto le permite usar mensajes de confirmación no estructurados al cometer cada pequeño cambio y luego aplastarlos en una sola confirmación con un mensaje estructurado (haciendo referencia al número de relaciones públicas) una vez que han sido revisados y aceptados.
standard-version para archivos de metadatos adicionales, idiomas o archivos de versión? A partir de la versión 7.1.0 , puede configurar múltiples bumpFiles y packageFiles .
filename bumpFile personalizado, esta es la ruta al archivo que desea "golpear"updater " bumpFile , así es como se superará el archivo. a. Si está utilizando un tipo común, puede usar una de updaters incorporadas de standard-version especificando un type . b. Si está utilizando un archivo de versión menos común, puede crear su propio 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 usa .versionrc.js como su archivo de configuración, el updater también se puede configurar como un objeto, en lugar de una ruta:
// .versionrc.js
const tracker = {
filename : 'VERSION_TRACKER.json' ,
updater : require ( './path/to/custom-version-updater' )
}
module . exports = {
bumpFiles : [ tracker ] ,
packageFiles : [ tracker ]
} updater personalizados s Se espera que un updater sea un módulo JavaScript con al menos dos métodos expuestos: readVersion y writeVersion .
readVersion(contents = string): stringEste método se utiliza para leer la versión del contenido del archivo proporcionado.
Se espera que el valor de retorno sea una cadena de versión semántica.
writeVersion(contents = string, version: string): stringEste método se utiliza para escribir la versión en el contenido proporcionado.
El valor de retorno se escribirá directamente (sobrescribir) al archivo proporcionado.
Supongamos que nuestra VERSION_TRACKER.json tiene los siguientes contenidos:
{
"tracker" : {
"package" : {
"version" : " 1.0.0 "
}
}
}
Un standard-version-updater.js sería:
// 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
