standard version
v9.5.0
standard-versioné preterida . Se você é um usuário do GitHub, recomendo a liberação-por favor, como alternativa. Se você não puder usar ações do GitHub ou se precisar seguir astandard-versionpor algum outro motivo, poderá usar o garfo de compromisso e versões dastandard-version.
Uma utilidade para versões usando a geração de Semver e Changelog, alimentada por commits convencionais.
Tendo problemas? Quer contribuir? Junte-se a nós na folga da comunidade de folhas de nó .
Como funciona:
standard-version . standard-version fará o seguinte:
packageFiles [1], voltando à última git tag .bump a versão em bumpFiles [1] com base em seus compromissos.changelog com base em seus compromissos (usa o changelog convencional sob o capô).commit , incluindo seus bumpFiles [1] e Changelog atualizado.tag com o novo número da versão.bumpFiles , packageFiles e updaters standard-version usa alguns conceitos-chave para lidar com a versão em seu projeto.
packageFiles -Arquivos definidos pelo usuário de onde as versões podem ser lidas e "esbarradas".package.json , manifest.jsonpackageFiles são um subconjunto de bumpFiles .bumpFiles -arquivos definidos pelo usuário onde as versões devem ser "esbarradas", mas não são explicitamente lidas.package-lock.json , npm-shrinkwrap.jsonupdaters - módulos simples usados para leitura de packageFiles e escrita para bumpFiles . Por padrão, standard-version pressupõe que você esteja trabalhando em um projeto baseado em NodeJS ... por causa disso, para a maioria dos projetos, talvez você nunca precise interagir com essas opções.
Dito isto, se você se perguntar, como posso usar a versão padrão para arquivos de metadados adicionais, idiomas ou arquivos de versão? - Essas opções de configuração ajudarão!
standard-versionnpm run Instale e adicione às devDependencies :
npm i --save-dev standard-version
Adicione um script npm run ao seu package.json :
{
"scripts" : {
"release" : " standard-version "
}
} Agora você pode usar npm run release no lugar da npm version .
Isso tem o benefício de tornar seu repositório/pacote mais portátil, para que outros desenvolvedores possam cortar lançamentos sem precisar instalar globalmente standard-version em sua máquina.
bin global Instale globalmente (adicione ao seu PATH ):
npm i -g standard-version
Agora você pode usar standard-version no lugar da npm version .
Isso tem o benefício de permitir que você use standard-version em qualquer repo/pacote sem adicionar uma dependência de dev a cada um.
npx A partir de [email protected] , npx está instalado ao lado npm . Usando npx você pode usar standard-version sem precisar manter um arquivo package.json executando: npx standard-version .
Este método é especialmente útil ao usar standard-version em projetos não-Javascript.
Você pode configurar standard-version por:
standard-version em seu package.json (assumindo que seu projeto seja JavaScript)..versionrc , .versionrc.json ou .versionrc.js ..versionrc.js sua exportação padrão deve ser um objeto de configuração ou uma função retornando um objeto de configuração. Qualquer um dos parâmetros da linha de comando aceito pela standard-version pode ser fornecido via configuração. Consulte a especificação convencional-Changelog-Config para obter detalhes sobre as opções de configuração disponíveis.
Por padrão (a partir de 6.0.0 ), standard-version usa a predefinição convencionalCommits.
Esta predefinição:
Há uma variedade de mostradores e botões que você pode se tornar relacionado à geração de changelog.
Como exemplo, suponha que você esteja usando o GitLab, em vez do GitHub, você pode modificar as seguintes variáveis:
commitUrlFormat : O formato de URL dos shas de comprometimento detectado em mensagens de confirmação.compareUrlFormat : o formato URL usado para comparar duas tags.issueUrlFormat : o formato URL usado para vincular a problemas.Fazendo esses URLs combinarem o formato de Gitlab, em vez de do GitHub.
Nota: Passar configurações aninhadas para a CLI sem defini -las no
package.jsonUse a notação de ponto como os parâmetroseg --skip.changelog.
Para gerar seu Changelog para o seu primeiro lançamento, basta fazer:
# npm run script
npm run release -- --first-release
# global bin
standard-version --first-release
# npx
npx standard-version --first-release Isso marcará uma versão sem esbarrar na versão bumpFiles 1 .
Quando estiver pronto, empurre a tag git e npm publish seu primeiro lançamento. o//
Se você normalmente usa npm version para cortar uma nova versão, faça isso:
# npm run script
npm run release
# or global bin
standard-versionDesde que suas mensagens de comprometimento git sejam convencionais e precisas, você não precisará mais especificar o tipo de semver - e você recebe geração de changelog gratuitamente! o//
Depois de cortar um lançamento, você pode empurrar a nova tag git e npm publish (ou npm publish --tag next ) quando estiver pronto.
Use a bandeira --prerelease para gerar pré-liberação:
Suponha que a última versão do seu código seja 1.0.0 , e seu código a ser comprometido tenha corrigido as alterações. Correr:
# npm run script
npm run release -- --prerelease Isso marcará sua versão como: 1.0.1-0 .
Se você deseja nomear o pré-lançamento, especificará o nome via --prerelease <name> .
Por exemplo, suponha que seu pré-lançamento deva conter o prefixo alpha :
# npm run script
npm run release -- --prerelease alpha Isso marcará a versão como: 1.0.1-alpha.0
npm version ) Para renunciar ao uso automatizado de Bump Uso --release-as com o argumento major , minor ou patch .
Suponha que a última versão do seu código seja 1.0.0 , você só atingiu fix: cometidos, mas gostaria que seu próximo lançamento seja minor . Basta executar o seguinte:
# npm run script
npm run release -- --release-as minor
# Or
npm run release -- --release-as 1.1.0 Você receberá a versão 1.1.0 em vez do que seria a versão 1.0.1 gerada automaticamente.
NOTA: Você pode combinar
--release-ase--prereleasepara gerar uma versão. Isso é útil ao publicar recursos experimentais.
Se você usar ganchos Git, como pré-compromisso, para testar seu código antes de se comprometer, poderá impedir que os ganchos sejam verificados durante a etapa de comprometimento, passando a opção --no-verify :
# npm run script
npm run release -- --no-verify
# or global bin
standard-version --no-verify Se você tiver sua tecla GPG configurada, adicione o sinalizador --sign ou -s ao seu comando standard-version .
standard-version suporta scripts do ciclo de vida. Isso permite que você execute seus próprios comandos suplementares durante a versão. Os ganchos a seguir estão disponíveis e executados no pedido documentado:
prerelease : executado antes que algo aconteça. Se o script prerelease retornar um código de saída diferente de zero, a versão será abortada, mas não terá outro efeito no processo.prebump / postbump : executado antes e depois que a versão é esbugalhada. Se o script prebump retornar uma versão #, ele será usado em vez da versão calculada por standard-version .prechangelog / postchangelog : Executa antes e depois que o Changelog é gerado.precommit / postcommit : chamado antes e depois da etapa de confirmação.pretag / posttag : chamado antes e depois da etapa de marcação.Basta adicionar o seguinte ao seu package.json para configurar scripts do ciclo de vida:
{
"standard-version" : {
"scripts" : {
"prebump" : " echo 9.9.9 "
}
}
} Como exemplo, a mudar do uso do GitHub para rastrear seus itens para usar seus projetos que Jira use um script postchangelog para substituir o fragmento de URL contendo 'https://github.com/`myproject`/issues/' com um link para o seu jira - assumindo que você já instalou
{
"standard-version" : {
"scripts" : {
"postchangelog" : " replace 'https://github.com/myproject/issues/' 'https://myjira/browse/' CHANGELOG.md "
}
}
} Você pode pular qualquer uma das etapas do ciclo de vida ( bump , changelog , commit , tag ), adicionando o seguinte ao seu package.json:
{
"standard-version" : {
"skip" : {
"changelog" : true
}
}
} Se você deseja cometer artefatos gerados no comprometimento da liberação, pode usar o sinalizador --commit-all ou -a . Você precisará encenar os artefatos que deseja cometer, para que seu comando release possa ficar assim:
{
"standard-version" : {
"scripts" : {
"prerelease" : " webpack -p --bail && git add <file(s) to commit> "
}
}
}{
"scripts" : {
"release" : " standard-version -a "
}
} A execução standard-version com o --dry-run permite que você veja quais comandos seriam executados, sem se comprometer a git ou atualizar arquivos.
# npm run script
npm run release -- --dry-run
# or global bin
standard-version --dry-run As tags são prefixadas com v por padrão. Se você deseja prefixar suas tags com outra coisa, pode fazê -lo com o sinalizador -t .
standard-version -t @scope/package @ Isso prefixará suas tags para parecer algo como @scope/[email protected]
Se você não deseja ter nenhum prefixo de tags, poderá usar o sinalizador -t e fornecer uma string vazia como valor.
NOTA: Simplesmente -t ou - -tag -prefixo sem qualquer valor fará fallback para o padrão '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 } ` )
} ) Dica: use a opção silent para impedir standard-version da impressão no console .
standard-version é diferente da semantic-release ? semantic-release é descrita como:
A liberação semântica automatiza todo o fluxo de trabalho de liberação do pacote, incluindo: determinando o próximo número da versão, gerando as notas de versão e publicando o pacote.
Embora ambos sejam baseados na mesma base de mensagens de comprometimento estruturado, standard-version adota uma abordagem diferente, manipulando o versão, a geração de changelog e a marcação de git para você sem empurrar automático (para o github) ou publicar (para um registro da NPM). O uso da standard-version afeta apenas o seu repositório Git local - isso não afeta os recursos remotos. Depois de executar standard-version , você pode revisar seu estado de liberação, erros corretos e seguir a estratégia de liberação que faz mais sentido para a sua base de código.
Achamos que ambos são ferramentas fantásticas, e incentivamos as pessoas a usar semantic-release em vez de standard-version se isso faz sentido para o seu caso de uso.
As instruções para a squash se comprometerem ao mesclar solicitações de puxar pressupõe que um PR seja igual, no máximo, um recurso ou correção .
Se você possui vários recursos ou correções de pouso em um único PR e cada Compromisso usa uma mensagem estruturada, poderá fazer uma mesclagem padrão ao aceitar o PR. Isso preservará o histórico de compromissos do seu ramo após a mesclagem.
Embora isso permitirá que cada comprometimento seja incluído como entradas separadas no seu Changelog, as entradas não poderão fazer referência ao PR que puxou as alterações porque as mensagens de comprometimento preservadas não incluem o número de PR.
Por esse motivo, recomendamos manter o escopo de cada RP em um recurso ou correção geral. Na prática, isso permite que você use mensagens de confirmação não estruturadas ao cometer cada pequena alteração e, em seguida, esmagá -las em um único commit com uma mensagem estruturada (referenciando o número de PR) depois de revisados e aceitos.
standard-version para arquivos de metadados adicionais, idiomas ou arquivos de versão? A partir da versão 7.1.0 você pode configurar vários bumpFiles e packageFiles .
filename bumpFile personalizado, este é o caminho para o arquivo que você deseja "Bump"bumpFile " updater ", é assim que o arquivo será atingido. um. Se você estiver usando um tipo comum, poderá usar um dos updaters internos da standard-version especificando um type . b. Se você estiver usando um arquivo de versão menos comum, poderá criar seu próprio 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"
}
]
} Se estiver usando .versionrc.js como seu arquivo de configuração, o updater também pode ser definido como um objeto, em vez de um caminho:
// .versionrc.js
const tracker = {
filename : 'VERSION_TRACKER.json' ,
updater : require ( './path/to/custom-version-updater' )
}
module . exports = {
bumpFiles : [ tracker ] ,
packageFiles : [ tracker ]
} updater personalizados s Espera -se que um updater seja um módulo JavaScript com pelo menos dois métodos expostos: readVersion e writeVersion .
readVersion(contents = string): stringEste método é usado para ler a versão do conteúdo do arquivo fornecido.
O valor de retorno deve ser uma string de versão semântica.
writeVersion(contents = string, version: string): stringEste método é usado para escrever a versão no conteúdo fornecido.
O valor de retorno será gravado diretamente (substituição) ao arquivo fornecido.
Vamos supor que nosso VERSION_TRACKER.json tenha o seguinte conteúdo:
{
"tracker" : {
"package" : {
"version" : " 1.0.0 "
}
}
}
Um aceitável standard-version-updater.js seria:
// 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
