UNPKG

yankee

Version:

Easy release management with YAML changelogs

177 lines (110 loc) 4.02 kB
[![Coveralls – test coverage ](https://img.shields.io/coveralls/studio-b12/yankee.svg?style=flat-square )](https://coveralls.io/r/studio-b12/yankee ) [![Travis – build status ](https://img.shields.io/travis/studio-b12/yankee/master.svg?style=flat-square )](https://travis-ci.org/studio-b12/yankee ) [![David – status of dependencies ](https://img.shields.io/david/studio-b12/yankee.svg?style=flat-square )](https://david-dm.org/studio-b12/yankee ) [![Code style: airbnb ](https://img.shields.io/badge/code%20style-airbnb-777777.svg?style=flat-square) ](https://github.com/airbnb/javascript) <a id="/"></a>&nbsp; # yankee **Easy release management with YAML changelogs** <a id="/installation"></a>&nbsp; ## Installation ```sh # As a global command: npm install --global yankee # …or locally for an npm project: npm install --save-dev yankee ``` <a id="/synopsis"></a>&nbsp; ## Synopsis ```sh yankee [<path>] yankee --help ``` <a id="/description"></a>&nbsp; ## Description The file `Changelog.yaml` is the single source of information about your releases. It should be an object with one key per release and an optional `master:` key at the top. Here’s an example: ```yaml master: new features: - The cool new flag `--verbose`. 2.0.1: date: 1992-02-09 fixed bugs: - Got rid of a nasty IO bug. - Improved the docs. 2.0.0: date: 1982-03-15 breaking changes: - API redesign. See the readme for details. 1.0.0: date: 1970-01-01 note: Initial release. ``` When you call `yankee`, we’ll determine what version number comes next and update the file accordingly. We’ll replace `master:` with the new version and add a `date:` property with the current day right below that. If the `master:` object contains the key `breaking changes:`, we’ll make it a major release (X.y.z). If it contains the key `new features:`, we’ll make a minor bump (x.Y.z). Otherwise, make sure your `master:` changelog has the key `fixed bugs:` – we’ll release it as a patch (x.y.Z). The version number against which we’ll be bumping is the first key in your `Changelog.yaml` except `master:`. If there’s no other key, we’ll always tag the release as 1.0.0. If you call `yankee` without any options, we’ll only output the version number, so that it’s easy for you to process with scripts. <a id="/options"></a>&nbsp; ## Options <!-- @options start --> #### `[path]` The path to your project directory. Should contain a `Changelog.yaml`. Default: `$(pwd)`. #### `-n, --npm` Attempt to update the `version` field in `package.json` and `npm-shrinkwrap.json`. #### `-c, --commit` Commit changes. The commit message will be the raw version number. #### `-t, --tag` Tag the commit with an annotated tag. The tag name will be the raw version number preceeded with a “v”. Implies `--commit`. #### `-h, --help` You’re looking at it. <!-- @options end --> <a id="/example"></a>&nbsp; ## Example Here a simple example using `cat` and [here docs](https://en.wikipedia.org/wiki/Here_document#Unix_shells). When creating your package, you start off with a simple changelog: ```yaml $ cat << ——— > Changelog.yaml master: note: Initial release. ——— ``` When you’re ready for a 1.0.0 release, just call `yankee`: ```yaml $ yankee 1.0.0 $ cat Changelog.yaml 1.0.0: date: 2016-05-20 note: Initial release. ``` Working on new stuff, update the changelog accordingly: ```yaml $ cat << ——— > Changelog.yaml master: new features: - Cool new stuff! $(cat Changelog.yaml) ——— ``` When ready for a release, `yankee` will figure out what the release number should be: ```yaml $ yankee 1.1.0 $ cat Changelog.yaml 1.1.0: date: 2016-05-20 new features: - Cool new stuff! 1.0.0: date: 2016-05-20 note: Initial release. ``` <a id="/license"></a>&nbsp; ## License [MIT](https://github.com/studio-b12/yankee/License.md) © [Studio B12](http://studio-b12.de)