coffeelint-config-marviq

Marviq's shareable coffeelint config baseline.

Contributing

Prerequisites

• npm and node
• git flow
• jq

Setup

Clone this repository somewhere, switch to it, then:

$ git config commit.template ./.gitmessage
$ git checkout master
$ git checkout develop
$ git flow init -d
$ npm install

This will:

• Set up a helpful reminder of how to make a good commit message. If you adhere to this, then a detailed, meaningful CHANGELOG can be constructed automatically;
• Ensure you have local master and develop branches tracking their respective remote counterparts;
• Set up the git flow branching model with default branch names;
• Install all required dependencies;

Commit

Branching Model

This project uses git flow. Here's a quick cheat sheet.

Commit Message Format Discipline

This project uses conventional-changelog/standard-version for automatic versioning and CHANGELOG management.

To make this work, please ensure that your commit messages adhere to the Commit Message Format. Setting your git config to have the commit.template as referenced below will help you with a detailed reminder of how to do this on every git commit.

$ git config commit.template ./.gitmessage

Release

• Determine what your next semver <version> should be:

  $ version="<version>"

• Create and checkout a release/v<version> branch off of develop:

  $ git flow release start "v${version}"

• Bump the package's .version, update the CHANGELOG, commit these, and tag the commit as v<version>:

  $ npm run release

• If all is well this new version should be identical to your intended <version>:

  $ jq ".version == \"${version}\"" package.json

  If this is not the case, then either your assumptions about what changed are wrong, or (at least) one of your commits did not adhere to the Commit Message Format Discipline; Abort the release, and sort it out first.

• Merge release/v<version> back into both develop and master, checkout develop and delete release/v<version>:

  $ git flow release finish -n "v${version}"

  Note that contrary to vanilla git flow, the merge commit into master will not have been tagged (that's what the -n was for). This is done because npm run release has already tagged its own commit.

  I believe that in practice, this won't make a difference for the use of git flow; and ensuring it's done the other way round instead would render the use of conventional-changelog impossible.

Publish

git checkout v<version>
npm publish
git checkout develop

License

BSD-3-Clause