aktualizuj wersję package.json automatycznie

Zanim zrobię małą wersję i oznaczę ją, chciałbym zaktualizować plik package.json, aby odzwierciedlić nową wersję programu.

Czy istnieje sposób package.jsonautomatycznej edycji pliku ?

Czy skorzystałbyś z git pre-release hookpomocy?

npm versionjest prawdopodobnie poprawną odpowiedzią. Żeby dać alternatywę, polecam chrząknięcie . Obsługuje go jeden z facetów z angular.js.

Stosowanie:

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

Jeśli mimo wszystko używasz chrząka, może to być najprostsze rozwiązanie.

Poprawna odpowiedź

Aby to zrobić, po prostu npm version patch=)

Moja stara odpowiedź

pre-releasePoczątkowo nie ma haka git. Przynajmniej man githookstego nie pokazuje.

Jeśli używasz git-extra( https://github.com/visionmedia/git-extras ), na przykład, możesz użyć pre-releasehaka, który jest przez niego implementowany, jak widać na https://github.com/visionmedia/ git-extras / blob / master / bin / git-release . Potrzebny jest tylko .git/hook/pre-release.shplik wykonywalny, który edytuje package.jsonplik. Zatwierdzanie, pchanie i oznaczanie będzie wykonywane przez git releasepolecenie.

Jeśli nie używasz żadnego rozszerzenia git, możesz napisać skrypt powłoki (nazwę go git-release.sh), a następnie możesz połączyć go git releasez aliasem za pomocą czegoś takiego:

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

Możesz, niż użyć, git release 0.4który zostanie wykonany path/to/pre-release.sh 0.4. Twój skrypt może edytować package.json, tworzyć znaczniki i przekazywać je na serwer.

Tak zwykle robię z moimi projektami:

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

Pierwszy wiersz npm version patchzwiększy wersję łatki o 1 (xx1 do xx2) w package.json. Następnie dodajesz wszystkie pliki - w tym te, package.jsonktóre w tym momencie zostały zmodyfikowane. Potem zazwyczaj git commiti git push, wreszcie npm publishopublikować moduł.

Mam nadzieję, że to ma sens...

Merc.

Aby zapewnić bardziej aktualne podejście.

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

Następnie uruchom:

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

Które będą:

1. ... uruchom testy ...

2. zmień package.jsonna następną mniejszą wersję (np .: 1.8.1 na 1.9.0)

3. popchnij swoje zmiany

4. utwórz nową wersję tagu git i

5. opublikuj swój pakiet npm.

--forcejest pokazanie, kto jest szefem! Żarty na bok patrz https://github.com/npm/npm/issues/8620

Jako dodatek npm versionmożesz użyć --no-git-tag-versionflagi, jeśli chcesz wersji wypukłości, ale nie ma tagu lub nowego zatwierdzenia:

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

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

Jeśli używasz przędzy, możesz jej użyć

yarn version --patch

Spowoduje to zwiększenie package.jsonwersji przez łatkę (0.0.x), zatwierdzenie i oznaczenie jej formatemv0.0.0

Podobnie możesz zderzyć mniejszą lub większą wersję za pomocą --minorlub--major

Pchając do git, upewnij się, że również wypychasz tagi za pomocą --follow-tags

git push --follow-tags

Możesz także utworzyć dla niego skrypt

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

Po prostu uruchom go, pisząc yarn release-it

Używam husky i git-branch-jest :

Od 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)",
    }
  }
}

Przed husky V1:

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

Przeczytaj więcej o wersji npm

Webpack lub Vue.js

Jeśli używasz webpacka lub Vue.js, możesz wyświetlić to w interfejsie użytkownika za pomocą wersji Auto-wstrzykiwania - wtyczka Webpack

NUXT

W nuxt.config.js:

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

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

Wewnątrz templatena przykład w stopce:

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

Chcę dodać jasności do odpowiedzi na to pytanie.

Nawet jeśli są tutaj odpowiedzi, które właściwie rozwiązują problem i zapewniają rozwiązanie, nie są one prawidłowe. Prawidłową odpowiedzią na to pytanie jest użycienpm version

Czy istnieje sposób automatycznej edycji pliku package.json?

Tak, co możesz zrobić, aby tak się stało, to uruchom npm versionpolecenie w razie potrzeby, możesz przeczytać więcej na ten temat tutaj npm wersja , ale podstawowe użycie byłoby npm version patchi dodałoby 3-cyfrową kolejność w twojej package.jsonwersji (1.0. X )

Czy skorzystanie z haka pre-release git pomoże?

Możesz skonfigurować uruchamianie npm versionpolecenia na haku przedpremierowym, tak jak potrzebujesz, ale to zależy, czy tego właśnie potrzebujesz w rurze CD / CI, ale bez npm versionpolecenia git pre-releasehak nie może nic zrobić „łatwo” zpackage.json

Powodem, dla którego npm versionjest poprawna odpowiedź jest następująca:

1. Jeśli użytkownik korzysta ze struktury folderów, w której ma package.json, używa, npmjeśli używa npm, ma dostęp do npm scripts.
2. Jeśli ma dostęp npm scripts, ma dostęp do npm versionpolecenia.
3. Za pomocą tego polecenia nie musi instalować niczego więcej w swoim komputerze lub rurze CD / CI, co w dłuższej perspektywie zmniejszy wysiłek związany z utrzymaniem projektu i pomoże w instalacji

Inne odpowiedzi, w których proponowane są inne narzędzia, są nieprawidłowe.

gulp-bump działa, ale wymaga innego dodatkowego pakietu, który może powodować problemy w dłuższej perspektywie (punkt 3 mojej odpowiedzi)

grunt-bump działa, ale wymaga innego dodatkowego pakietu, który może powodować problemy w dłuższej perspektywie (punkt 3 mojej odpowiedzi)

Najpierw musisz zrozumieć zasady uaktualniania numeru wersji. Możesz przeczytać więcej o wersji semantycznej tutaj.

Każda wersja będzie miała wersję xyz, w której definiuje się ją w innym celu, jak pokazano poniżej.

1. x - major, w górę, gdy masz poważne zmiany i jest ogromna rozbieżność zmian.
2. y - drobne, do góry, gdy pojawi się nowa funkcjonalność lub rozszerzenie.
3. z - łatka, w górę, gdy masz naprawione błędy lub przywróć zmiany we wcześniejszej wersji.

Aby uruchomić skrypty, możesz to zdefiniować w pliku package.json.

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

W swoim terminalu wystarczy uruchomić npm odpowiednio do swoich potrzeb

npm run buildpatch

Jeśli uruchomisz go w git repo, domyślna wersja git-tag-true ma wartość true, a jeśli nie chcesz tego robić, możesz dodać poniższe polecenie do swoich skryptów:

--no-git-tag-version

na przykład: "npm --no-git-tag-version version major && ng build --prod"

Stworzyłem narzędzie, które może realizować automatyczne wersjonowanie semantyczne na podstawie znaczników w komunikatach zatwierdzania, znanych jako typy zmian. Jest to ściśle zgodne z Konwencją Angular Commit Message i specyfikacją wersjonowania semantycznego.

Możesz użyć tego narzędzia, aby automatycznie zmienić wersję pliku package.json przy użyciu interfejsu wiersza polecenia npm (opisano to tutaj ).

Ponadto może tworzyć dziennik zmian na podstawie tych zatwierdzeń, a także ma menu (z funkcją sprawdzania pisowni komunikatów zatwierdzania) do tworzenia zatwierdzeń na podstawie typu zmiany. Bardzo polecam sprawdzenie i przeczytanie dokumentów, aby zobaczyć wszystko, co można z tym zrobić.

Napisałem to narzędzie, ponieważ nie mogłem znaleźć niczego, co odpowiadałoby moim potrzebom dla mojego rurociągu CICD do automatyzacji wersjonowania semantycznego. Wolę skupić się na faktycznych zmianach niż na wersji i właśnie tam moje narzędzie oszczędza dzień.

Aby uzyskać więcej informacji na temat uzasadnienia dla narzędzia, zobacz to .