This document is meant to be a brief "checklist" of things to setup for your Ember addon when beginning development in order to have the best possible architecture and workflow out of the gate. For comprehensive, reference-manual-style material, the following are bookshelf-caliber:

• Ember CLI's Official Addon Guide

• Ember Addon Secrets - Written around the Ember 2.6 era, this article takes a much deeper dive into several of the topics mentioned here.

• Write a good description
• Use helpful keywords
• Specify a author info
• Specify a repo
• Are you using Ember Data? If not, it can be safely removed from package.json to lighten your dependency load.
  • npm uninstall --save-dev ember-data

A rule of thumb when determining whether a module should be listed under dependencies or devDependencies: Ask whether any specific code from this module will be executed when your addon's code is executed by its consuming project. If so, make it a dependency.

• For example, ember-cli-mirage runs a mock client-side server in consuming applications, and that code itself relies on a pretender dependency

This used to be a bit dirty, but thankfully, @mike_north has created a super-useful addon that encapsulates CI configurations with Chrome in both Travis and Circle CI.

ember install ember-ci

ember-try's pre-generated setup is golden, but you might also want to include support for the current Ember LTS release:

In .travis.yml:

  - EMBER_TRY_SCENARIO=default
  - EMBER_TRY_SCENARIO=ember-1.13
  - EMBER_TRY_SCENARIO=ember-lts-2.4
  - EMBER_TRY_SCENARIO=ember-release
  - EMBER_TRY_SCENARIO=ember-beta
  - EMBER_TRY_SCENARIO=ember-canary

These are some of the badges that I've found to be the most useful when looking at a project:

• npm package
• Circle Build Status
  • or Travis Build Status
• Code Climate
• Coveralls
• Ember Observer Score
• dependencies Status
• devDependencies Status
• License

That's a lot of linking, though, so here's a Gist of how something like this can be put together in Markdown.

Even if your addon isn't concerned with custom blueprints, having a basic default blueprint is extremely useful for npm linking the addon into another project while developing it.

Default blueprints are always a good idea:

ember g blueprint <ADDON_NAME>

And here's all it should look like:

module.exports = {
 description: 'install <ADDON_NAME> into a project',

 normalizeEntityName: function() {}
};

ember-release is a tremendously useful (and built-in) tool that can be used with any particular branching philosophy -- but it gels quite nicely with git flow:

1. git flow init

2. Create an awesome stuff and ready a release

3. Bump the project version (appropriately) from your release branch - ember release (and its variants)

• PR the release branch back into master

• npm publish when CI goes green 🚀🚀🚀

• Why?
  • Supercool way to show off your addon
  • Use it to run acceptance tests against the current version
• How

  • Establish a workflow for building a dummy app and pushing it to your repository's gh-pages branch.

    • ember-cli-github-pages is your best friend.

  • In the ember-addon hash of your package.json, set the demoURL property to the hosted address

    "ember-addon": {
      "configPath": "tests/dummy/config"
      "demoURL": "{{GITHUB_PAGES_URL}}"
    }