Bump async

[calvinmetcalf]

makes 2 1/2 changes

1. adds a bump command which increments each of the packages by the specified amount, major, minor, patch, and prerelease are supported, if no field is present it defaults to '0.0.0' so that doing bump minor would give you 0.1.0, also adds tests and updates the readme.
2. makes it async, currently the program reads a file, does the stuff, writes it, and then looks to the next file, used the async file methods so file 2 doesn't have to wait around for file 1 to finish writing before it can start, should be faster (through who knows by how much).

Also I fixed a typo in the readme.

[jprichardson]

Thanks for implementing the bump, I like it a lot! However, the async changes alter the clarity of the code for little gain (I'd wager less than a few ms). Would you be willing to resubmit with just the bump code?

[calvinmetcalf]

yes I can resubmit sans the async code, a few quick notes

• on normal file systems they should be more or less the same, if a hard drive is being slow, async will degrade better
• this cartoon
• On a serious note my actual impetus was that fs.exists is not recommended, this is going to apply to the sync version as well.

[jprichardson]

Meh, adhering to dogma of using only async versions in all cases seems a bit silly; especially for CLI apps. What's wrong with fs.exists? At any rate, I do really appreciate your interest and contributions (sincerely).

[calvinmetcalf]

the issue is that if a different program modifies it between fs.exists and then trying to open it, aka something else is deleting it, also I reverted the async stuff yesterday and then to forget to push it woops, pushed, tin is greate we use it in pouchdb and proj4js publish scripts

[jprichardson]

Looks like npm may be having some issues, I'll publish it later.

[calvinmetcalf]

yeah its down