aggiorna automaticamente la versione di package.json

Prima di fare una piccola release e taggarla, vorrei aggiornare package.json per riflettere la nuova versione del programma.

C'è un modo per modificare package.jsonautomaticamente il file ?

Userebbe un git pre-release hookaiuto?

npm versionè probabilmente la risposta corretta. Giusto per dare un'alternativa, raccomando grunt-bump . È gestito da uno dei ragazzi di 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 stai usando grunt comunque, potrebbe essere la soluzione più semplice.

Risposta esatta

Per fare ciò, solo npm version patch=)

La mia vecchia risposta

pre-releaseOriginariamente non è presente alcun gancio git. Almeno, man githooksnon lo mostra.

Se stai usando git-extra( https://github.com/visionmedia/git-extras ), ad esempio, puoi usare un pre-releasehook che è implementato da esso, come puoi vedere su https://github.com/visionmedia/ git-extra / blob / master / bin / git-release . È necessario solo un .git/hook/pre-release.shfile eseguibile che modifica il package.jsonfile. Commettere, spingere e taggare sarà fatto dal git releasecomando.

Se non si utilizza alcuna estensione per git, è possibile scrivere uno script di shell (lo chiamerò git-release.sh) e quindi si può alias git releasecon qualcosa del tipo:

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

È possibile, quindi, utilizzare git release 0.4quale verrà eseguito path/to/pre-release.sh 0.4. Lo script può essere modificato package.json, creare il tag e inviarlo al server.

Questo è ciò che faccio normalmente con i miei progetti:

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

La prima riga, npm version patchaumenterà la versione della patch di 1 (da xx1 a xx2) in package.json. Quindi aggiungi tutti i file, incluso package.jsonquale a quel punto è stato modificato. Quindi, il solito git commite git push, infine, npm publishper pubblicare il modulo.

Spero che abbia senso ...

Merc.

Per dare un approccio più aggiornato.

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"
  }

Quindi lo esegui:

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

Quale:

1. ... esegui test ...

2. passare package.jsonalla versione successiva successiva (ad es. da 1.8.1 a 1.9.0)

3. spingi le tue modifiche

4. creare una nuova versione del tag git e

5. pubblica il tuo pacchetto npm.

--forceè mostrare chi è il capo! Scherzi a parte vedi https://github.com/npm/npm/issues/8620

Come aggiunta a npm versionte puoi usare il --no-git-tag-versionflag se vuoi un bump della versione ma nessun tag o un nuovo commit:

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

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

Se stai usando un filato puoi usarlo

yarn version --patch

Questo aumenterà la package.jsonversione per patch (0.0.x), commit e tag con formatov0.0.0

Allo stesso modo è possibile eseguire il bump della versione minore o maggiore utilizzando --minoro--major

Quando si preme per git assicurarsi di spingere anche i tag con --follow-tags

git push --follow-tags

Puoi anche creare uno script per questo

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

Basta eseguirlo digitando yarn release-it

Sto usando husky e git-branch-is :

A partire da 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)",
    }
  }
}

Prima di husky V1:

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

Maggiori informazioni sulla versione di npm

Webpack o Vue.js

Se stai usando webpack o Vue.js, puoi visualizzarlo nell'interfaccia utente usando la versione Auto Inject - plugin Webpack

NUXT

In nuxt.config.js:

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

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

Dentro templatead esempio nel piè di pagina:

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

Voglio aggiungere un po 'di chiarezza alle risposte ottenute da questa domanda.

Anche se ci sono alcune risposte qui che affrontano correttamente il problema e forniscono una soluzione, non sono quelle giuste. La risposta corretta a questa domanda è usarenpm version

C'è un modo per modificare automaticamente il file package.json?

Sì, ciò che puoi fare per far sì che ciò accada è eseguire il npm versioncomando quando necessario, puoi leggere di più qui npm version , ma l'utilizzo di base sarebbe npm version patche aggiungerebbe l'ordine della 3a cifra sulla tua package.jsonversione (1.0. X )

L'uso di un hook di pre-release git sarebbe di aiuto?

È possibile configurare per eseguire il npm versioncomando sull'hook pre-release, se necessario, ma ciò dipende se questo è ciò di cui si ha bisogno o meno nella propria pipe CD / CI, ma senza il npm versioncomando un git pre-releasehook non può fare nulla "facilmente" con ilpackage.json

Il motivo per cui npm versionè la risposta corretta è il seguente:

1. Se l'utente sta usando una struttura di cartelle in cui ha una package.json, sta usando, npmse sta usando npm, ha accesso a npm scripts.
2. Se ha accesso npm scripts, ha accesso al npm versioncomando.
3. Usando questo comando non ha bisogno di installare altro nel suo computer o pipe CD / CI che a lungo termine ridurrà lo sforzo di manutenibilità per il progetto e aiuterà con l'installazione

Le altre risposte in cui vengono proposti altri strumenti sono errate.

gulp-bump funziona ma richiede un altro pacchetto aggiuntivo che potrebbe creare problemi a lungo termine (punto 3 della mia risposta)

grunt-bump funziona ma richiede un altro pacchetto aggiuntivo che potrebbe creare problemi a lungo termine (punto 3 della mia risposta)

Innanzitutto, è necessario comprendere le regole per l'aggiornamento del numero di versione. Puoi leggere di più sulla versione semantica qui.

Ogni versione avrà la versione xyz in cui definisce per scopi diversi, come mostrato di seguito.

1. x - maggiore, questo quando si verificano cambiamenti importanti ed è presente un'enorme discrepanza tra i cambiamenti.
2. y - minore, fino a quando si verificano nuove funzionalità o miglioramenti.
3. z - patch, fino a quando hai bug corretti o ripristina le modifiche nella versione precedente.

Per eseguire gli script, è possibile definirlo in package.json.

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

Nel tuo terminale, devi solo eseguire npm in base alle tue esigenze

npm run buildpatch

Se lo esegui in git repo, la versione predefinita di git-tag è vera e se non desideri farlo, puoi aggiungere il seguente comando nei tuoi script:

--no-git-tag-version

per esempio: "npm --no-git-tag-version version major && ng build --prod"

Ho creato uno strumento in grado di realizzare il controllo automatico delle versioni semantiche basato sui tag nei messaggi di commit, noti come tipi di modifica. Ciò segue da vicino la Convenzione sui messaggi di impegno angolare insieme alle specifiche semantiche sul controllo delle versioni.

È possibile utilizzare questo strumento per modificare automaticamente la versione in package.json utilizzando l'interfaccia della riga di comando npm (questa è descritta qui ).

Inoltre, può creare un log delle modifiche da questi commit e ha anche un menu (con un controllo ortografico per i messaggi di commit) per la creazione di commit in base al tipo di modifica. Consiglio vivamente di verificarlo e leggere i documenti per vedere tutto ciò che può essere realizzato con esso.

Ho scritto lo strumento perché non sono riuscito a trovare nulla adatto alle mie esigenze per la mia pipeline CICD per automatizzare il versioning semantico. Preferirei concentrarmi su quali siano le modifiche effettive piuttosto che su come dovrebbe essere la versione ed è qui che il mio strumento salva la giornata.

Per ulteriori informazioni sulla logica dello strumento, vedere questo .