atualize a versão package.json automaticamente

Antes de fazer um lançamento pequeno e marcá-lo, gostaria de atualizar o package.json para refletir a nova versão do programa.

Existe uma maneira de editar o arquivo package.jsonautomaticamente?

Usando uma git pre-release hookajuda?

npm versionprovavelmente é a resposta correta. Só para dar uma alternativa, eu recomendo o grunhido . É mantido por um dos caras do angular.js.

Uso:

grunt bump
>> Version bumped to 0.0.2

grunt bump:patch
>> Version bumped to 0.0.3

grunt bump:minor
>> Version bumped to 0.1.0

grunt bump
>> Version bumped to 0.1.1

grunt bump:major
>> Version bumped to 1.0.0

Se você estiver usando o grunhido de qualquer maneira, pode ser a solução mais simples.

Resposta correta

Para fazer isso, apenas npm version patch=)

Minha antiga resposta

Não há pre-releasegancho originalmente em git. Pelo menos, man githooksnão mostra isso.

Se você estiver usando git-extra( https://github.com/visionmedia/git-extras ), por exemplo, poderá usar um pre-releasegancho implementado por ele, como você pode ver em https://github.com/visionmedia/ git-extras / blob / master / bin / git-release . É necessário apenas um .git/hook/pre-release.sharquivo executável que edite seu package.jsonarquivo. A confirmação, envio e marcação serão feitos pelo git releasecomando.

Se você não estiver usando nenhuma extensão git, poderá escrever um shell script (eu o nomeio git-release.sh) e, em seguida, aliasá-lo git releasecom algo como:

git config --global alias.release '!sh path/to/pre-release.sh $1'

Você pode, então, usar o git release 0.4que será executado path/to/pre-release.sh 0.4. Seu script pode editar package.json, criar a tag e enviá-la ao servidor.

Isto é o que eu normalmente faço com meus projetos:

npm version patch
git add *;
git commit -m "Commit message"
git push
npm publish

A primeira linha npm version patch,, aumentará a versão do patch em 1 (xx1 a xx2) em package.json. Em seguida, você adiciona todos os arquivos - incluindo os package.jsonque foram modificados naquele momento. Em seguida, o habitual git commite git push, e, finalmente, npm publishpublicar o módulo.

Espero que isto faça sentido...

Merc.

Para fornecer uma abordagem mais atualizada.

package.json

  "scripts": {
    "eslint": "eslint index.js",
    "pretest": "npm install",
    "test": "npm run eslint",
    "preversion": "npm run test",
    "version": "",
    "postversion": "git push && git push --tags && npm publish"
  }

Então você o executa:

npm version minor --force -m "Some message to commit"

Qual irá:

1. ... executar testes ...

2. mude package.jsonpara uma próxima versão secundária (por exemplo: 1.8.1 a 1.9.0)

3. empurre suas mudanças

4. crie uma nova versão da tag git e

5. publique seu pacote npm.

--forceé mostrar quem é o chefe! Piadas à parte, consulte https://github.com/npm/npm/issues/8620

Como complemento, npm versionvocê pode usar o --no-git-tag-versionsinalizador se desejar um aumento de versão, mas nenhuma tag ou uma nova confirmação:

npm --no-git-tag-version version patch

https://docs.npmjs.com/cli/version

Se você estiver usando fio, você pode usar

yarn version --patch

Isso incrementará a package.jsonversão por correção (0.0.x), confirmação e marcação com o formatov0.0.0

Da mesma forma, você pode encontrar a versão secundária ou secundária usando --minorou--major

Ao pressionar para o git, certifique-se de também enviar as tags com --follow-tags

git push --follow-tags

Você também pode criar um script para ele

    "release-it": "yarn version --patch && git push --follow-tags"

Basta executá-lo digitando yarn release-it

Estou usando husky e git-branch-is :

A partir do husky v1 +:

// package.json
{
  "husky": {
    "hooks": {
      "post-merge": "(git-branch-is master && npm version minor || 
  (git-branch-is dev && npm --no-git-tag-version version patch)",
    }
  }
}

Antes da V1 rouca:

"scripts": {
  ...
  "postmerge": "(git-branch-is master && npm version minor || 
  (git-branch-is dev && npm --no-git-tag-version version patch)",
  ...
},

Leia mais sobre a versão npm

Webpack ou Vue.js

Se você estiver usando o webpack ou o Vue.js, poderá exibi-lo na interface do usuário usando a versão Injetar automaticamente - plugin Webpack

NUXT

Em nuxt.config.js:

var WebpackAutoInject = require('webpack-auto-inject-version');

module.exports = {
  build: {
    plugins: [
      new WebpackAutoInject({
        // options
        // example:
        components: {
          InjectAsComment: false
        },
      }),
    ]
  },
}

Dentro do seu templatepor exemplo no rodapé:

<p> All rights reserved © 2018 [v[AIV]{version}[/AIV]]</p>

Quero acrescentar um pouco de clareza às respostas que esta pergunta obteve.

Mesmo pensando que existem algumas respostas aqui que abordam adequadamente o problema e fornecem uma solução, elas não são as corretas. A resposta correta para esta pergunta é usarnpm version

Existe uma maneira de editar o arquivo package.json automaticamente?

Sim, o que você pode fazer para que isso aconteça é executar o npm versioncomando quando necessário, você pode ler mais sobre ele aqui na versão npm , mas o uso básico seria npm version patche incluiria a ordem do terceiro dígito em sua package.jsonversão (1.0. X )

Usar um gancho de pré-lançamento do git ajudaria?

Você pode configurar para executar o npm versioncomando no gancho de pré-lançamento, conforme necessário, mas isso depende se é disso que você precisa ou não no seu canal de CD / CI, mas sem o npm versioncomando, um git pre-releasegancho não pode fazer nada "facilmente" com opackage.json

A razão pela qual npm versioné a resposta correta é a seguinte:

1. Se o usuário estiver usando uma estrutura de pastas na qual package.jsonele está usando, npmse estiver usando, npmele terá acesso ao npm scripts.
2. Se ele tem acesso, npm scriptsele tem acesso ao npm versioncomando.
3. Usando esse comando, ele não precisa instalar mais nada em seu computador ou canal de CD / CI, o que a longo prazo reduzirá o esforço de manutenção do projeto e ajudará na instalação.

As outras respostas nas quais outras ferramentas são propostas estão incorretas.

gulp-bump funciona, mas requer outro pacote extra que pode criar problemas a longo prazo (ponto 3 da minha resposta)

grunt-bump funciona, mas requer outro pacote extra que pode criar problemas a longo prazo (ponto 3 da minha resposta)

Primeiro, você precisa entender as regras para atualizar o número da versão. Você pode ler mais sobre a versão semântica aqui.

Cada versão terá a versão xyz, onde será definida para finalidades diferentes, como mostrado abaixo.

1. x - major, faça isso quando houver grandes alterações e ocorrer uma grande discrepância de alterações.
2. y - menor, faça isso quando ocorrer uma nova funcionalidade ou aprimoramento.
3. z - patch, faça isso quando você tiver erros corrigidos ou reverter alterações na versão anterior.

Para executar os scripts, você pode defini-lo em seu package.json.

"script": {
    "buildmajor": "npm version major && ng build --prod",
    "buildminor": "npm version minor && ng build --prod",
    "buildpatch": "npm version patch && ng build --prod"
}

No seu terminal, você só precisa executar o npm de acordo com suas necessidades, como

npm run buildpatch

Se executá-lo no git repo, a versão padrão do git-tag é verdadeira e, se você não quiser, pode adicionar o comando abaixo nos seus scripts:

--no-git-tag-version

por exemplo: "npm --no-git-tag-version version major && ng build --prod"

Eu criei uma ferramenta que pode realizar o controle de versão semântico automático com base nas tags nas mensagens de confirmação, conhecidas como tipos de alteração. Isso segue de perto a Convenção de Mensagem de Compromisso Angular, juntamente com a Especificação de Versão Semântica.

Você pode usar esta ferramenta para alterar automaticamente a versão no package.json usando a CLI do npm (isso é descrito aqui ).

Além disso, ele pode criar um log de alterações a partir dessas confirmações e também possui um menu (com um verificador ortográfico para mensagens de confirmação) para criar confirmações com base no tipo de alteração. Eu recomendo conferir e ler os documentos para ver tudo o que pode ser realizado com ele.

Eu escrevi a ferramenta porque não consegui encontrar nada que atendesse às minhas necessidades para o meu CICD Pipeline para automatizar o controle de versão semântico. Prefiro me concentrar no que são as mudanças reais do que na versão e é aí que minha ferramenta salva o dia.

Para mais informações sobre a justificativa da ferramenta, consulte isso .