Ember Addon Essentials -- A checklist of some of the finer details to keep in mind when developing Ember addons

ember-addon-essentials.md

Ember Addon Essentials

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.

Filling out package.json

• 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

dependencies or devDependencies?

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

Configuring CI

Consider Installing and Running Chrome in CI tests

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

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

Filling out your README.md

Badging FTW

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

Here's a Gist of the Markdown needed to put these all together.

Generate a default blueprint for your addon

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>

Managing versions and publishing with ember-release (& and possibly git flow)

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 🚀🚀🚀

Creating A Demo? Deploy your dummyApp to GitHub Pages!

• 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}}"
    }