Package.json version bumper
npm install bampA version bump utility for node.js packages
npm install -g bamp
npm install --save-dev bamp
package.json:
"scripts": {
"bamp": "bamp"
}
Usage:
npm run bamp -- -switches
bamp [switches] [prerelease tags]
For example, bamp -bc development might produce a version number of 1.0.3-1.development
By default, bamp does not make any changes. It will print out the resulting version after processing for you to verify.
You must specify --commit to create changes; this will write the new version to package.json and, if possible, commit the change to git.
major, minor, and patch specify which portion of the version string to bump. Semver semantics apply, so bumping the minor version from 1.2.3 will yield 1.3.0
There is a slight addition here which doesn't seem to exist in other similar modules, which is the build version. The first integer, if present, in the prerelease version (in semver, this is the bolded portion of: major.minor.patch-prerelease.tags+build.metadata), will be taken as the build number; if you bump this value, it will be increased accordingly, and if you bump the patch version, it will be reset to zero. Furthermore, if you specify any prerelease tags, they will also be added to the version. Any existing prerelease tags are dropped in this process.
In other words, if you were to execute bamp -b on each of the following, you would get 1.0.0-1:
- 1.0.0
- 1.0.0-0
- 1.0.0-foo
And if you were to execute bamp -b bar on each of the following, you would get 1.0.0-1.bar:
- 1.0.0
- 1.0.0-0
- 1.0.0-foo
Build metadata is preserved, however, so bamp -b with an input of 1.0.0-foo+bar would produce 1.0.0-1+bar.
Options:
-v, --verbose Show what's going on in detail
-m, --major Bump the major version number
-n, --minor Bump the minor version number
-p, --patch Bump the patch version number
-b, --build Bump the build pre-release version
-r, --release Drop pre-release and build metadata tags
-c, --commit Apply changes to package.json (and commit changes to git, if available
-t, --tag Create a git tag for this version
-u, --git-push Push changes upstream (and tags, if created)
-U, --publish Publish to NPM
--assert-branch Fail if active branch is not equal to specified branch
These are pretty self-explanatory. There are switches to commit to git, create a tag, push the results, and publish to NPM. These occur in the order you would expect: if you create a tag, the tag gets pushed; the published version contains the new version from package.json, etc.
--assert-branch requires the active git branch to be equal to the specified git branch before performing any destructive action.