обновить версию package.json автоматически

Перед тем, как сделать небольшой выпуск и отметить его, я бы хотел обновить файл package.json, чтобы он отражал новую версию программы.

Есть ли способ редактировать файл package.jsonавтоматически?

Будет ли использовать git pre-release hookпомощь?

npm versionнаверное правильный ответ. Просто чтобы дать альтернативу, я рекомендую grunt-bump . Он поддерживается одним из парней из angular.js.

Использование:

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

Если вы все равно используете grunt, это может быть самым простым решением.

Правильный ответ

Для этого просто npm version patch=)

Мой старый ответ

Там нет pre-releaseкрючка изначально git. По крайней мере, man githooksне показывает это.

Например, если вы используете git-extra( https://github.com/visionmedia/git-extras ), вы можете использовать реализованный им pre-releaseхук, как вы можете видеть на https://github.com/visionmedia/ git-extras / blob / master / bin / git-release . Нужен только .git/hook/pre-release.shисполняемый файл, который редактирует ваш package.jsonфайл. Фиксация, нажатие и пометка будут выполнены git releaseкомандой.

Если вы не используете какое-либо расширение для git, вы можете написать сценарий оболочки (я назову его git-release.sh), а затем вы можете присвоить ему псевдоним что- git releaseто вроде:

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

Вы можете, чем, использовать git release 0.4который будет выполнять path/to/pre-release.sh 0.4. Ваш скрипт может редактировать package.json, создавать тег и отправлять его на сервер.

Это то, что я обычно делаю со своими проектами:

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

Первая строка, npm version patchувеличит версию патча на 1 (xx1 до xx2) в package.json. Затем вы добавляете все файлы, включая те, package.jsonкоторые на данный момент были изменены. Затем обычный git commitи git push, наконец, npm publishопубликовать модуль.

Я надеюсь это имеет смысл...

Merc.

Чтобы дать более современный подход.

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

Затем вы запускаете это:

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

Который будет:

1. ... запустить тесты ...

2. измените свою package.jsonверсию на следующую минорную (например, с 1.8.1 до 1.9.0)

3. подтолкнуть ваши изменения

4. создать новый выпуск тегов git и

5. опубликуйте свой пакет npm.

--forceэто показать, кто в доме хозяин! Шутки в сторону см. Https://github.com/npm/npm/issues/8620

В дополнение к этому npm versionвы можете использовать --no-git-tag-versionфлаг, если вы хотите повысить версию, но не добавить тег или новый коммит:

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

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

Если вы используете пряжу, вы можете использовать

yarn version --patch

Это увеличит package.jsonверсию патчем (0.0.x), зафиксирует и пометит его в форматеv0.0.0

Точно так же вы можете поднять минорную или мажорную версию с помощью --minorили--major

При нажатии на git убедитесь, что вы также нажимаете на теги --follow-tags

git push --follow-tags

Вы также можете создать скрипт для него

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

Просто запустите его, набрав yarn release-it

Я использую лайки и git-branch-is :

По состоянию на хаски 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)",
    }
  }
}

До хаски V1:

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

Узнайте больше о версии npm

Webpack или Vue.js

Если вы используете webpack или Vue.js, вы можете отобразить это в пользовательском интерфейсе, используя версию Auto inject - плагин Webpack

NUXT

В nuxt.config.js:

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

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

Внутри вашего, templateнапример, в нижнем колонтитуле:

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

Я хочу внести ясность в ответы на этот вопрос.

Даже при том, что есть некоторые ответы, которые правильно решают проблему и предлагают решение, они не являются правильными. Правильный ответ на этот вопрос заключается в использованииnpm version

Есть ли способ отредактировать файл package.json автоматически?

Да, то, что вы можете сделать, чтобы это произошло, - это запустить npm versionкоманду при необходимости, вы можете прочитать больше об этом здесь, версия npm , но базовое использование будет, npm version patchи это добавит 3-й порядок цифр в вашей package.jsonверсии (1.0. X )

Поможет ли использование git pre-release hook?

Вы можете настроить запуск npm versionкоманды на предварительном хуке, как вам нужно, но это зависит от того, что вам нужно или нет в вашем канале CD / CI, но без npm versionкоманды git pre-releaseхук не может ничего сделать «легко» сpackage.json

Причина npm versionправильного ответа заключается в следующем:

1. Если пользователь использует структуру папок, в которой он имеет, package.jsonон использует, npmесли он использует, npmон имеет доступ к npm scripts.
2. Если он имеет доступ к нему, npm scriptsон имеет доступ к npm versionкоманде.
3. С помощью этой команды ему не нужно больше устанавливать что-либо на свой компьютер или канал CD / CI, что в долгосрочной перспективе снизит затраты на сопровождение проекта и поможет с настройкой

Другие ответы, в которых предлагаются другие инструменты, неверны.

gulp-bump работает, но требует другого дополнительного пакета, который может создать проблемы в долгосрочной перспективе (пункт 3 моего ответа)

grunt-bump работает, но требует другого дополнительного пакета, который может создать проблемы в долгосрочной перспективе (пункт 3 моего ответа)

Во-первых, вам необходимо понять правила обновления номера версии. Вы можете прочитать больше о семантической версии здесь.

Каждая версия будет иметь версию XYZ, где она определяется для различных целей, как показано ниже.

1. x - Major, это когда у вас есть серьезные изменения, и это огромные расхождения произошли изменения.
2. у - второстепенный, до этого, когда у вас есть новые функциональные возможности или улучшения произошли.
3. z - патч, исправьте это, если у вас исправлены ошибки или отменены изменения в более ранней версии.

Чтобы запустить сценарии, вы можете определить это в вашем package.json.

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

В вашем терминале вам просто нужно запустить npm в соответствии с вашими потребностями, такими как

npm run buildpatch

Если запустить его в git repo, по умолчанию используется git-tag-версия true, и если вы не хотите этого делать, вы можете добавить в свои сценарии следующую команду:

--no-git-tag-version

например: "npm --no-git-tag-version version major && ng build --prod"

Я создал инструмент, который может выполнять автоматическое семантическое управление версиями на основе тегов в сообщениях фиксации, известный как типы изменений. Это близко следует Соглашению об Angular Commit Message вместе со Спецификацией Семантического Версионирования.

Вы можете использовать этот инструмент для автоматического изменения версии в package.json с помощью CLI npm (это описано здесь ).

Кроме того, он может создать журнал изменений из этих коммитов, а также имеет меню (с проверкой орфографии для сообщений коммитов) для создания коммитов на основе типа изменений. Я настоятельно рекомендую проверить это и прочитать документы, чтобы увидеть все, что может быть достигнуто с этим.

Я написал инструмент, потому что не смог найти ничего, что соответствовало бы моим потребностям в CICD Pipeline для автоматизации семантического управления версиями. Я бы предпочел сосредоточиться на реальных изменениях, а не на том, какой должна быть версия, и именно там мой инструмент экономит день.

Для получения дополнительной информации об обосновании инструмента, пожалуйста, смотрите это .