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 more comprehensive 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

Writing a good README

Badging FTW

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.

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>

And here's all it should look like:

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

 normalizeEntityName: function() {}
};

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