Grunt plugin for automating all the release steps of your node lib or bower component, with optional publishing to npm.
Releasing a new version of your killer Node/Bower/Component/JS lib looks something like this:
- bump the version in your
package.json
file. - stage the package.json file's change.
- commit that change with a message like "release 0.6.22".
- create a new git tag for the release.
- push the changes out to github.
- also push the new tag out to github.
- publish the new version to npm.
Cool, right? No! What's wrong with you? Automate all that:
grunt release
Done. No more github issues reminding you how often you forget to do one or more of the steps.
If you haven't used Grunt before, be sure to check out the Getting Started guide, as it explains how to create a Gruntfile as well as install and use Grunt plugins. Once you're familiar with that process, you may install this plugin with this command:
npm install grunt-release --save-dev
Once the plugin has been installed, it may be enabled inside your Gruntfile with this line of JavaScript:
grunt.loadNpmTasks('grunt-release');
Patch Release:
grunt release
or
grunt release:patch
Minor Release:
grunt release:minor
Major Release:
grunt release:major
Pre-release
grunt release:prerelease
prerelease
will just update the number after MAJOR.MINOR.PATCH
(eg: 1.0.0-1
)
If you want to add an alphanumeric identifier, you will need to add it by hand.
Example: add -alpha.0
to get something like 1.0.0-alpha.0
. Calling grunt release:prerelease
will just update the last number to 1.0.0-alpha.1
.
Releasing Unstable/Beta Versions
Sometimes it is useful to publish an 'unstable' or 'beta' version to npm
, while leaving your last stable release as the default that gets installed on an npm install
.
npm
accomplishes this using the --tag myUnstableVersion
flag. You can enable this flag in grunt-release either by setting the npmtag
option:
release: {
options: {
npmtag: 'canary',
}
}
or by passing the CLI arg:
grunt release --npmtag canary
NOTE: If the tag you pass is true, then the tag will be the new version number after the bump. Otherwise it will be the string you provided.
Dry Run:
To see what grunt-release does, without really changing anything, use --no-write
option.
grunt --no-write -v release
You'll see something like:
Parsing package.json...OK
Not actually writing package.json...OK
>> Version bumped to 0.2.6
Not actually running: git add package.json
Not actually running: git commit package.json -m "release 0.2.6"
>> package.json committed
Not actually running: git tag 0.2.6 -m "version 0.2.6"
>> New git tag created: 0.2.6
Done, without errors.
You can disable any of the steps if you want, by adding this to your Gruntfile:
release: {
options: {
bump: false, //default: true
file: 'component.json', //default: package.json,
files: ['CHANGELOG.md'], //default: []
changelog: 'changelog', //default: false (a string containing the changelog task to run)
add: false, //default: true
commit: false, //default: true
tag: false, //default: true
push: false, //default: true
pushTags: false, //default: true
npm: false, //default: true
npmtag: true, //default: no tag
folder: 'folder/to/publish/to/npm' //default project root
tagName: 'some-tag-<%= version %>', //default: '<%= version %>'
commitMessage: 'check out my release <%= version %>', //default: 'release <%= version %>'
tagMessage: 'tagging version <%= version %>' //default: 'Version <%= version %>'
}
}
For node libs, leave file
option blank. For bower components, set it to component.json
or whatever you've set your bower config file to be.
Inspired by Vojta Jina's grunt-bump.
MIT