The seed for pretty much any api I write in node.js

See the file : ./test/@util/example-full-schema.js for an annotated description of what each schema can do

• Set your app info in the package.json file
• Go through the todo's in the seed api and make decisions based on your needs.
• metadata fields to move to their own file, update the hydrate to use this file instead
• Adding the role to a newly created user.
• how to debug es6+ code in WebStorm - https://blog.jetbrains.com/webstorm/2015/05/ecmascript-6-in-webstorm-transpiling/

The Twelve-Factor App Recommends not storing your config in files, there are some pretty good reasons for and against this which can be read here. In my personal experience and based on how my projects run, I find that the advantages of file-based far outweigh the downsides, feel free to disagree. If you would prefer pure env config, check out dotenv or simply update the config code here to not load from file.

We use winston to route our logs to various places as required, and override console.x as per this article here to allow us to see what's happening with dependencies we may be using.

See http://keepachangelog.com/en/0.3.0/ for best parctices and justification on maintaining a changelog.

1. Merge in the pull request(s) on GitHub that make up the release.
2. Decide based on what is going into the release how the version number is going to change, see Semantic Versioning for more info.
3. The CHANGELOG.md file should have pending changes documented in the Unreleased section, create a new heading for this version and cut the relevant changes and paste them into the new section.
4. Run the npm command to increment the version number and tag it npm version [major | minor | patch | premajor | preminor | prepatch | prerelease] -m "A message that makes sense"
5. Push the updated branch & tag back to origin.
6. Run chandler push to push the notes from CHANGELOG.md to the GitHub release page. See chandler for more