Skip to content

Instantly share code, notes, and snippets.

@BrianSipple
Last active April 17, 2017 18:27
Show Gist options
  • Save BrianSipple/9f8090f2e868f10c45c5e63b44bbeaa1 to your computer and use it in GitHub Desktop.
Save BrianSipple/9f8090f2e868f10c45c5e63b44bbeaa1 to your computer and use it in GitHub Desktop.
Ember Addon Essentials -- A checklist of some of the finer details to keep in mind when developing Ember addons

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:

Filling out package.json

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.

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:

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() {}
};

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.

    • 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}}"
      }
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment