Before I do a small release and tag it, I\'d like to update the package.json to reflect the new version of the program.
Is there a way to edit the file package
With Husky:
{
"name": "demo-project",
"version": "0.0.3",
"husky": {
"hooks": {
"pre-commit": "npm --no-git-tag-version version patch"
}
}
}
I am using husky and git-branch-is:
As of 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)",
}
}
}
Prior to husky V1:
"scripts": {
...
"postmerge": "(git-branch-is master && npm version minor ||
(git-branch-is dev && npm --no-git-tag-version version patch)",
...
},
Read more about npm version
Webpack or Vue.js
If you are using webpack or Vue.js, you can display this in the UI using Auto inject version - Webpack plugin
NUXT
In nuxt.config.js
:
var WebpackAutoInject = require('webpack-auto-inject-version');
module.exports = {
build: {
plugins: [
new WebpackAutoInject({
// options
// example:
components: {
InjectAsComment: false
},
}),
]
},
}
Inside your template
for example in the footer:
<p> All rights reserved © 2018 [v[AIV]{version}[/AIV]]</p>
First, you need to understand the rules for upgrading the versioning number. You can read more about the semantic version here.
Each version will have x.y.z version where it defines for different purpose as shown below.
To run the scripts, you can define it in your package.json.
"script": {
"buildmajor": "npm version major && ng build --prod",
"buildminor": "npm version minor && ng build --prod",
"buildpatch": "npm version patch && ng build --prod"
}
In your terminal, you just need to npm run accordingly to your needs like
npm run buildpatch
If run it in git repo, the default git-tag-version is true and if you do not wish to do so, you can add below command into your scripts:
--no-git-tag-version
for eg: "npm --no-git-tag-version version major && ng build --prod"
To give a more up-to-date approach.
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"
}
Then you run it:
npm version minor --force -m "Some message to commit"
Which will:
... run tests ...
change your package.json
to a next minor version (e.g: 1.8.1 to 1.9.0)
push your changes
create a new git tag release and
publish your npm package.
--force
is to show who is the boss! Jokes aside see https://github.com/npm/npm/issues/8620
Right answer
To do so, just npm version patch
=)
My old answer
There is no pre-release
hook originally in git
. At least, man githooks
does not show it.
If you're using git-extra
(https://github.com/visionmedia/git-extras), for instance, you can use a pre-release
hook which is implemented by it, as you can see at https://github.com/visionmedia/git-extras/blob/master/bin/git-release. It is needed only a .git/hook/pre-release.sh
executable file which edits your package.json
file. Committing, pushing and tagging will be done by the git release
command.
If you're not using any extension for git
, you can write a shell script (I'll name it git-release.sh
) and than you can alias it to git release
with something like:
git config --global alias.release '!sh path/to/pre-release.sh $1'
You can, than, use git release 0.4
which will execute path/to/pre-release.sh 0.4
. Your script can edit package.json
, create the tag and push it to the server.
I have created a tool that can accomplish automatic semantic versioning based on the tags in commit messages, known as change types. This closely follows the Angular Commit Message Convention along with the Semantic Versioning Specification.
You could use this tool to automatically change the version in the package.json using the npm CLI (this is described here).
In addition, it can create a changelog from these commits and also has a menu (with a spell checker for commit messages) for creating commits based on the change type. I highly recommend checking it out and reading to docs to see everything that can be accomplished with it.
I wrote the tool because I couldn't find anything that suited my needs for my CICD Pipeline to automate semantic versioning. I'd rather focus on what the actual changes are than what the version should be and that's where my tool saves the day.
For more information on the rationale for the tool, please see this.