A 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.