ember CLI

Version 0.1.4

The command line interface for ambitious web applications.

npm install -g ember-cli View User Guide


Ember CLI is an Ember.js command line utility which provides a fast asset pipeline powered by broccoli and strong conventional project structure.

Ember CLI was based on the Ember App Kit Project which is now deprecated.

Assets Compilation

Ember CLI asset compilation is based on broccoli.

Broccoli has support for:

You can find a list of available plugins here.

All of this compilation happens in the background while you’re developing, rebuilding each time you change a file.


Ember CLI uses the ES6 Module Transpiler, which turns ES6 module syntax into AMD (RequireJS-style) modules. Using the transpiler, you can write code using tomorrow’s syntax, today.

In the past, building an Ember application with any sort of module system required you to wire up lots of pieces manually. Now, with the custom resolver included in Ember CLI, your modules are automatically imported when needed. For example, your route in routes/post.js will know to use the controller in controllers/post.js and the template in templates/post.hbs. Of course, if your application does need to explicitly include a module, it’s only an import statement away.

Testing using CLI

All apps built with Ember CLI are preconfigured to use QUnit, the Ember Testing package, and the Ember QUnit. These tools, along with the same module system as your application, make both unit and integration tests a breeze to write.

Dependency Management

Ember CLI uses the Bower package manager, making it easy to keep your front-end dependencies up to date. NPM is used to manage internal dependencies but you can also use it to introduce your own.

Runtime Configuration

Ember CLI can use a configuration file named .ember-cli in your home directory. In this file you can include any command-line options in a json file with the commands camelized; as in the following example:

# ~/.ember-cli
  "skipGit" : true,
  "port" : 999,
  "host" : "",
  "liveReload" : true,
  "environment" : "mock-development",
  "checkForUpdates" : false

Content security policy

Ember CLI comes bundled with the ember-cli-content-security-policy addon which enables the Content Security Policy in modern browsers when running the development server. When enabled, the Content Security Policy guards your application against the risks of XSS attacks. While browser support is still limited, ember-cli makes it easy to build your app with the CSP in mind. This means enabling it on your production stack will mean little more than adding the correct header.


Ember CLI is still very much WIP. It’s an ongoing community effort. We welcome your issues and PRs for features, bug fixes, and anything that would improve your quality of life as an Ember developer.

Talk to us here:


Currently, Ember CLI supports node 0.10.5 and npm 1.4.6.


The Ember App Kit project has proved to be quite useful. We have learned lots, and it allowed us to iterate quickly while building real ambitious applications.

While its initial incarnation is useful, it has several meta problems:

  1. It is not “simple” and appears daunting
  2. Because of inline configuration, the API surface area is massive
  3. 2 does not allow users to express the “what”, just the “how”. This prevents EAK from doing more of the heavy lifting itself
  4. 2 and 3 makes it quite tedious to upgrade

Rationale for #3

If we want to upgrade or swap in a faster build pipeline it would be a major pain currently. But with #3, in theory, it should be minimal pain.

Getting Started



First, install the latest stable version of Node (version 0.10.x).

To do so, either follow the installation instructions on nodejs.org, or use your preferred package manager (such as Homebrew on OS X) if you have one.

After installing Node, verify that Node is set up correctly by typing the following commands on the command line. Both should output help messages:

node --help
npm --help

Ember CLI

Once you’ve installed Node, you’ll need to install the Ember CLI globally with:

npm install -g ember-cli

This will give you access to the ember command-line runner.


You’ll need to install Bower, a package manager that keeps your front-end dependencies (including JQuery, Ember, and QUnit) up to date. This is as easy as running:

npm install -g bower

This will give you access to the bower command-line runner.


By default, your integration tests will run on PhantomJS. You can install via npm:

npm install -g phantomjs

Create a new project

Run the generator for your project:

ember new my-new-app

This will create a new my-new-app folder and generate an application structure for you.

Once the generation process finishes, launch the app:

cd my-new-app
ember server

navigate to http://localhost:4200 to see your new app in action.

navigate to http://localhost:4200/tests to see your test results in action.

Cloning an existing project

Alternatively, if you are checking out an existing Ember project created with ember-cli, you will need to install dependencies yourself before running the server:

git clone git@github.com:me/my-app.git
cd my-app && npm install && bower install
ember server

Using Ember CLI

Command Purpose
ember Prints out a list of available commands.
ember new <app-name> Creates a folder called <app-name> and generates an application structure for you. If git is available the folder will be initialized as a git repository and an initial commit will be created. Use --skip-git flag to disable this feature.
ember init Generates an application structure for you in the current folder.
ember build Builds the application to dist/ directory (customize via --output-path flag). Use --environment flag to specify the environment to build for (defaults to development). Use --watch flag keep the process running, observing the filesystem and rebuilding when changes occur.
ember server Starts up the server. Default port is 4200. Use --proxy flag to proxy all ajax requests to the given address. For example ember server --proxy will proxy all your apps XHR to your server running at port 8080.
ember generate <generator-name> <options> Runs a specific generator. To see available generators, run ember help generate.
ember test Run tests with Testem on CI mode. You can pass any options to Testem through testem.json, by default we’ll search for it under your project’s root or you can specify config-file.

Folder Layout

File/folder Purpose
app/ Contains your Ember application’s code. Javascript files in this folder are compiled through the ES6 module transpiler and concatenated into a file called app.js. See the table below for more details.
dist/ Contains the distributable (that is, optimized and self-contained) output of your application. Deploy this to your server!
public/ This folder will be copied verbatim into the root of your built application. Use this for assets that don’t have a build step, such as images or fonts.
tests/ Includes unit and integration tests for your app, as well as various helpers to load and run your tests.
tmp/ Various temporary output of build steps, as well as the debug output of your application (tmp/public).
bower_components/ Your dependencies, both those included with Ember CLI and those installed with Bower.
vendor/ Your external dependencies not installed with Bower or Npm.
.jshintrc JSHint configuration.
.gitignore Git configuration for ignored files.
Brocfile.js Contains build specification for Broccoli.
bower.json Bower configuration and dependency list. See Managing Dependencies.
package.json NPM configuration. Mainly used to list the dependencies needed for asset compilation.

Layout within app folder

File/folder Purpose
app/app.js Your application’s entry point. This is the module that is first executed.
app/index.html The only actual page of your single-page app! Includes dependencies and kickstarts your Ember application. See app/index.html.
app/router.js Your route configuration. The routes defined here correspond to routes in app/routes/.
app/styles/ Contains your stylesheets, whether SASS, LESS, Stylus, Compass, or plain CSS (though only one type is allowed, see Asset Compilation). These are all compiled into app.css.
app/templates/ Your Handlebars templates. These are compiled to templates.js. The templates are named the same as their filename, minus the extension (i.e. templates/foo/bar.hbs -> foo/bar).
app/controllers/, app/models/, etc. Modules resolved by the Ember CLI resolver. See Using Modules & the Resolver.


The app/index.html file lays the foundation for your application. This is where the basic DOM structure is laid out, the title attribute is set and stylesheet/javascript includes are done. In addition to this, app/index.html includes multiple hooks - {{content-for 'head'}} and {{content-for 'body'}} - that can be used by Add-ons to inject content into your application’s head or body. These hooks need to be left in place for your application to function properly, but they can be safely ignored unless you are working directly with a particular add-on.


Add-ons are registered in NPM with a keyword of ember-addon. See a full list of existing add-ons registered in NPM here.

Using Modules & the Resolver

The Ember Resolver is the mechanism responsible for looking up code in your application and converting its naming conventions into the actual classes, functions, and templates that Ember needs to resolve its dependencies, for example, what template to render for a given route. For an introduction to the Ember Resolver, and a basic example of how it actually works, see this video by Robert Jackson.

In the past, Ember’s Default Resolver worked by putting everything into a global namespace, so you will come across the following pattern:

1 App.IndexRoute = Ember.Route.extend({
2   model: function() {
3     return ['red', 'yellow', 'blue'];
4   }
5 });

Today, Ember CLI uses a newer version of the Resolver based on ES6 semantics. This means that you can build your apps using syntax from future JavaScript versions, but output AMD modules that can be used by existing JavaScript libraries today.

For example, this route definition in app/routes/index.js would result in a module called your-app/routes/index. Using the resolver, when Ember looks up the index route, it will find this module and use the object that it exports.

 1 // app/routes/index.js
 2 import Ember from "ember";
 4 var IndexRoute = Ember.Route.extend({
 5   model: function() {
 6     return ['red', 'yellow', 'blue'];
 7   }
 8   });
10   export default IndexRoute;

Note, that the name of the variable used in the exported module doesn’t have any influence on the resolver. It’s the filename that is used to resolve modules.

This variant of the Resolver will replace the default resolver in Ember 2.0.

Additional Examples

You can also export modules directly without having to declare a variable:

1 import Ember from "ember";
3 export default Ember.Route.extend({
4   model: function() {
5     return ['red', 'yellow', 'blue'];
6   }
7 });

You can also require modules directly with the following syntax:

1 import FooMixin from "./mixins/foo";

If you like you can reference a module by an absolute path, but keep in mind that using relative paths is considered best practice for accessing modules within the same package. To reference a module using an absolute path begin the path with the name defined in package.json:

1 import FooMixin from "appname/mixins/foo";

Similarly, you can give any name to the variable into which you import a module when doing so manually; see how the module mixins/foo is assigned to variable FooMixin in the example above.

Using Ember or Ember Data

To use Ember or DS (for Ember Data) in your modules you must import them:

1 import Ember from "ember";
2 import DS from "ember-data";

Using Pods

One of the enhancements that the new Resolver brings is that it will first look for Pods before the traditional project structure.

Cyclic Dependencies

Cyclic dependencies – are not yet supported at the moment, we are depending on es6-module-transpiler/pull/126

Module Directory Naming Structure

Folder Purpose
app/adapters/ Adapters with the convention adapter-name.js.
app/components/ Components with the convention component-name.js. Components must have a dash in their name. So blog-post is an acceptable name, but post is not.
app/controllers/ Controllers with the convention controller-name.js. Child controllers are defined in sub-directories, parent/child.js.
app/helpers/ Helpers with the convention helper-name.js. Remember that you must register your helpers by exporting makeBoundHelper or calling registerBoundHelper explicitly.
app/initializers/ Initializers with the convention initializer-name.js. Initializers are loaded automatically.
app/mixins/ Mixins with the convention mixin-name.js.
app/models/ Models with the convention model-name.js.
app/routes/ Routes with the convention route-name.js. Child routes are defined in sub-directories, parent/child.js. To provide a custom implementation for generated routes (equivalent to App.Route when using globals), use app/routes/basic.js.
app/serializers/ Serializers for your models or adapter, where model-name.js or adapter-name.js.
app/transforms/ Transforms for custom Ember Data attributes, where attribute-name.js is the new attribute.
app/utils/ Utility modules with the convention utility-name.js.
app/views/ Views with the convention view-name.js. Sub-directories can be used for organization.

All modules in the app folder can be loaded by the resolver but typically classes such as mixins and utils should be loaded manually with an import statement.

For more information, see Naming Conventions.

Resolving from template helpers

Ember has several template helpers that are used to easily resolve and render views and their contexts within a template. The resolver works with these helpers, too:

Template Helper Example Purpose
partial {{partial "foo"}} Renders the template within templates/foo.hbs
view {{view "foo"}} Renders the view within views/foo.js
render {{render "foo" <context>}} Renders the view within views/foo.js using the controller within controllers/foo.js and the template templates/foo.hbs

Resolving Handlebars helpers

Custom Handlebars helpers are one of the ways that you can use the same HTML multiple times in your web application. Registering your custom helper allows it to be invoked from any of your Handlebars templates. Custom helpers are located under app/helpers. If your custom helper contains a dash(upper-case, reverse-word, etc.), it will be found and loaded automatically by the resolver.

1 // app/helpers/upper-case.js
2 import Ember from "ember";
4 export default Ember.Handlebars.makeBoundHelper(function(value, options) {
5   return value.toUpperCase();
6 });

In some-template.hbs:

{{upper-case "foo"}}

Limiting automatically-loaded helpers to those that contain dashes is an explicit decision made by Ember. It helps disambiguate properties from helpers, and helps mitigate the performance hit of helper resolution for all bindings. The other loading option is to define only the function used by the helper and to load it explicitly:

 1 // app/helpers/trim.js
 2 export default function(value, options) {
 3   return value.trim();
 4 };
 6 // app.js
 7 import Ember from "ember";
 8 import trimHelper from './helpers/trim';
10 Ember.Handlebars.registerBoundHelper('trim', trimHelper);

In some-template.hbs:

{{trim "     foo"}}

In this example the helper is loaded explicitly. It’s the first argument to registerBoundHelper which makes the Handlebars renderer find it. The file name (trim.js) and the name of the variable it’s been imported into (trimHelper) could have been anything.

A common pattern with helpers is to define a helper to use your views (e.g. for a custom text field view, MyTextField a helper my-text-field to use it). It is advised to leverage Components instead. More concretely, instead of:

 1 // app/views/my-text-field.js
 2 import Ember from "ember";
 3 export default Ember.TextField.extend({
 4   // some custom behaviour
 5 });
 7 // app/helpers/my-text-field.js... the below does not work!!!
 8 import Ember from "ember";
 9 import MyTextField from 'my-app/views/my-text-field';
11 Ember.Handlebars.helper('my-text-field', MyTextField);

Do this:

1 // Given... app/components/my-text-field.js
2 import Ember from "ember";
4 export default Ember.TextField.extend({
5   // some custom behaviour...
6 });

Using global variables or external scripts

If you want to use external libraries that write to a global namespace (e.g. moment.js), you need to add those to the predef section of your project’s .jshintrc file and set its value to true. If you use the lib in tests, you need to add it to your tests/.jshintrc file, too.

Module import validation

To prevent errors in import statements from reaching production, this project uses grunt-es6-import-validate. This task parses each module file’s export and import statements and verifies that what is being imported is actually exported by the referenced module.

If you are referencing a vendor module that is defined outside of the app folder you may have to add it to the whitelist in tasks/options/validate-imports.js.

Naming Conventions

When using Ember CLI it’s important to keep in mind that the Resolver changes some of the naming conventions you would typically use out of the box with Ember, Ember Data and Handlebars. In this section we review some of these naming conventions.

Module Examples

1 // app/adapters/application.js
2 import Ember from "ember";
3 import DS from "ember-data";
5 export default DS.RESTAdapter.extend({});
1 // app/components/time-input.js
2 import Ember from "ember";
4 export default Ember.TextField.extend({});
1 // app/controllers/stop-watch.js
2 import Ember from "ember";
4 export default Ember.ObjectController.extend({});

And if it’s a nested controller, we can declare nested/child controllers like such: app/controllers/posts/index.js.

1 // app/helpers/format-time.js
2 import Ember from "ember";
4 export default Ember.Handlebars.makeBoundHelper(function(){});
1 // app/initializers/observation.js
2 export default {
3   name: 'observation',
4   initialize: function() {
5     // code
6   }
7 };

Note: initializers are loaded automatically.

1 // app/mixins/evented.js
2 import Ember from "ember";
4 export default Ember.Mixin.create({});
1 // app/models/observation.js
2 import DS from "ember-data";
4 export default DS.Model.extend({});
1 // app/routes/timer.js
2 import Ember from "ember";
4 export default Ember.Route.extend({});

Nested routes as such: app/routes/timer/index.js or app/routes/timer/record.js.

1 // app/serializers/observation.js
2 import DS from "ember-data";
4 export default DS.RESTSerializer.extend({});
1 // app/transforms/time.js
2 import DS from "ember-data";
4 export default DS.Transform.extend({});
1 // app/utils/my-ajax.js
2 export default function myAjax() {};
<!-- app/index.hbs -->
{{view 'stop-watch'}}
1 // app/views/stop-watch.js
2 import Ember from "ember";
4 export default Ember.View.extend({});

And views, which can be referenced in sub-directories, but have no inheritance.

<!-- app/index.hbs -->
{{view 'inputs/time-input'}}
1 // app/views/inputs/time-input.js
2 import Ember from "ember";
4 export default Ember.TextField.extend({});


It is important to keep in mind that the Resolver uses filenames to create the associations correctly. This helps you by not having to namespace everything yourself. But there are a couple of things you should know.

  • Dashes
    • file names
    • folder names
    • html tags/ember components
    • CSS classes
    • URLs
  • camelCase
    • JavaScript
    • JSON
All filenames should be lowercased
1 // models/user.js
2 import Ember from "ember";
3 export default Ember.Model.extend();
// controllers/sign-up.js
import Ember from "ember";
export default Ember.Controller.extend();
Nested directories

If you prefer to nest your files to better manage your application, you can easily do so.

1 // controllers/posts/new.js results in a controller named "controllers.posts/new"
2 import Ember from "ember";
3 export default Ember.Controller.extend();

You cannot use paths containing slashes in your templates because Handlebars will translate them back to dots. Simply create an alias like this:

1 // controllers/posts.js
2 import Ember from "ember";
3 export default Ember.Controller.extend({
4   needs: ['posts/details'],
5   postsDetails: Ember.computed.alias('controllers.posts/details')
6 });
<!-- templates/posts.hbs -->
<!-- because {{controllers.posts/details.count}} does not work -->

Views and Templates

Let’s say we were using Ember out of the box with the following view:

import Ember from "ember";
App.UserView = Ember.View.extend({});

We could easily embed this view into a container/parent using the Handlebars view helper:

{{view App.UserView}}

This is great. However, Ember CLI customizes the default Ember Resolver to help alleviate the issue of namespacing your objects (views, controllers, models, etc.) manually. The above example, as such, will not work in an Ember CLI project.

In Ember CLI our view would be declared like so:

1 // app/views/user.js
2 import Ember from "ember";
3 export default Ember.View.extend({});

We can then embed our view using the following convention:

{{view "user"}}

Note, that we did not namespace UserView. The resolver takes care of this for you. For more information about the default Ember resolver, check out the source here.


Test filenames should be suffixed with -test.js in order to run.

Pod structure

As your app gets bigger, a feature-driven structure may be better. Splitting your application by functionality/resource would give you more power and control to scale and maintain it. As a default, if the file is not found on the POD structure, the Resolver will look it up within the normal structure.

In this case, you should name the file as its functionality. Given a resource Users, the folder structure would be:

  • app/users/controller.js
  • app/users/route.js
  • app/users/template.hbs

Rather than hold your resource folders on the root of your app you can define a POD path using the attribute podModulePrefix within your environment configs. The POD path should use the following format: {appname}/{poddir}.

 1 // config/environment.js
 2 module.exports = function(environment) {
 3   var ENV = {
 4     modulePrefix: 'my-new-app',
 5     // namespaced directory where resolver will look for your resource files
 6     podModulePrefix: 'my-new-app/pods',
 7     environment: environment,
 8     baseURL: '/',
 9     locationType: 'auto'
10     //...
11   };
13   return ENV;
14 };

Then your folder structure would be:

  • app/pods/users/controller.js
  • app/pods/users/route.js
  • app/pods/users/template.hbs

Using With Ember Data

The current beta Ember Data is included with Ember CLI.

Ember Data has recently undergone a major reboot, drastically simplifying it and making it easier to use with the Ember resolver. Here’s some tips for using it within Ember CLI.

To use ember-cli without Ember Data remove the dependency from package.json (the same applies for ic-ajax)

npm rm ember-data --save-dev


Models are critical in any dynamic web application. Ember Data makes making models extremely easy.

For example, we can create a todo model like so:

 1 // models/todo.js
 2 import DS from "ember-data";
 4 export default DS.Model.extend({
 5   title: DS.attr('string'),
 6   isCompleted: DS.attr('boolean'),
 7   quickNotes: DS.hasMany('quick-note')
 8 });
10 // models/quick-note.js
11 import DS from "ember-data";
13 export default DS.Model.extend({
14   name: DS.attr('string'),
15   todo: DS.belongsTo('todo')
16 });

Note, that filenames should be all lowercase and dasherized - this is used by the Resolver automatically.

Adapters & Serializers

Ember Data makes heavy use of per-type adapters and serializers. These objects can be resolved like any other.

Adapters can be placed at /app/adapters/type.js:

1 // adapters/post.js
2 import DS from "ember-data";
4 export default DS.RESTAdapter.extend({});

And its serializer can be placed in /app/serializers/type.js:

1 // serializers/post.js
2 import DS from "ember-data";
4 export default DS.RESTSerializer.extend({});

Application-level (default) adapters and serializers should be named adapters/application.js and serializers/application.js, respectively.

Mocks and fixtures

If you’re used to using fixtures to get test data into your app during development, you won’t be able to create fixture data like you’re used to doing (i.e. as specified in the guides). This is because the models in your Ember CLI app (like all other objects) aren’t attached to the global namespace.

Ember CLI comes with an http-mock generator which is preferred to fixtures for development and testing. Mocks have several advantages over fixtures, a primary one being that they interact with your application’s adapters. Since you’ll eventually be hooking your app up to a live API, it’s wise to be testing your adapters from the onset.

To create a mock for a posts API endpoint, use

ember g http-mock posts

A basic ExpressJS server will be scaffolded for your endpoint under /your-app/server/mocks/posts.js. Once you add the appropriate JSON response, you’re ready to go. The next time you run ember serve, your new mock server will be listening for any API requests from your Ember app.

Note: Mocks are just for development and testing. The entire /server directory will be ignored during ember build.

If you decide to use fixtures instead of mocks, you’ll need to use reopenClass within your model class definitions. First, create a fixture adapter, either for a single model or your entire application:

1 // adapters/application.js
2 import DS from "ember-data";
4 export default DS.FixtureAdapter.extend({});

Then add fixture data to your model class:

 1 // models/author.js
 2 import DS from "ember-data";
 4 var Author = DS.Model.extend({
 5   firstName: DS.attr('string'),
 6   lastName: DS.attr('string')
 7 });
 9 Author.reopenClass({
10   FIXTURES: [
11     {id: 1, firstName: 'Bugs', lastName: 'Bunny'},
12     {id: 2, firstName: 'Wile E.', lastName: 'Coyote'}
13   ]
14 });
16 export default Author;

Your Ember app’s API requests will now use your fixture data.


Running existing tests

Running your Tests is as easy as one of these two commands:

ember test            # will run your test-suite in your current shell once
ember test --server   # will run your tests on every file-change

Alternatively you can run the tests in your regular browser using the QUnit interface. Run ember server and navigate to http://localhost:4200/tests. In this case, the tests will run in your default environment, usually ‘development’.

Writing a Test

  • ember-testing
  • helpers
  • unit/acceptance

The default tests in Ember CLI use the QUnit library. The included tests demonstrate how to write both unit tests and acceptance/integration tests using the new ember-testing package.

Test filenames should be suffixed with -test.js in order to run.

If you are using Pods to organize your application, be sure to add your podModulePrefix to the test resolver namespace.

If you have manually set the locationType in your environment.js to hash or none you need to update your tests/index.html to have absolute paths (/assets/vendor.css and /testem.js vs the default relative paths).

CI Mode with Testem

ember test will run your tests with Testem on CI mode. You can pass any option to Testem using a configuration file.

If you are capturing output from the Testem xunit reporter, use ember test --silent to silence unwanted output such as the ember-cli version.

By default, your integration tests will run on PhantomJS. You can install via npm:

npm install -g phantomjs

We plan to make your test runner pluggable, so you can use your favorite runner.

Using ember-qunit for integration tests

All Ember Apps come with built-in ember test helpers, which are useful for writing integration tests. In order to use them, you will need to import tests/helpers/start-app.js, which injects the required helpers.

Be sure to use the injected module function to invoke setup and teardown.

 1 import Ember from "ember";
 2 import { test } from 'ember-qunit';
 3 import startApp from '../helpers/start-app';
 4 var App;
 6 module('An Integration test', {
 7   setup: function() {
 8     App = startApp();
 9   },
10   teardown: function() {
11     Ember.run(App, App.destroy);
12   }
13 });
15 test("Page contents", function() {
16   expect(2);
17   visit('/foos').then(function() {
18     equal(find('.foos-list').length, 1, "Page contains list of models");
19     equal(find('.foos-list .foo-item').length, 5, "List contains expected number of models");
20   });
21 });

Using ember-qunit for unit tests

An Ember CLI-generated project comes pre-loaded with ember-qunit which includes several helpers to make your unit-testing life easier, i.e.:

  • moduleFor
  • moduleForModel
  • moduleForComponent
moduleFor(fullName, description, callbacks, delegate)

The generic resolver that will load what you specify. The usage closely follows QUnit’s own module function. Its use can be seen within the supplied index-test.js:

 1 import { test, moduleFor } from 'ember-qunit';
 3 moduleFor('route:index', "Unit - IndexRoute", {
 4   // only neccessary if you want to load other items into the runtime
 5   // needs: ['controller:index']
 6   setup: function () {},
 7   teardown: function () {}
 8 });
10 test("it exists", function(){
11   ok(this.subject());
12 });


The resolver friendly name of the object you are testing.


The description that will group all subsequent tests under. Defaults to the fullname.


You are able to supply custom setup, teardown, & subject functionality by passing them into the callbacks parameter. If other objects should be loaded into Ember.js, specify the objects through the needs property.


To manually modify the container & the testing context, supply a function as the delegate matching this signature delegate(container, testing_context).

this.subject() calls the factory for the object specified by the fullname and will return an instance of the object.

moduleForModel(name, description, callbacks)

Extends the generic moduleFor with custom loading for testing models:

 1 import DS from 'ember-data';
 2 import Ember from 'ember';
 3 import { test, moduleForModel } from 'ember-qunit';
 5 moduleForModel('post', 'Post Model', {
 6   needs: ['model:comment']
 7 });
 9 test('Post is a valid ember-data Model', function () {
10   var store = this.store();
11   var post = this.subject({title: 'A title for a post', user: 'bob'});
12   ok(post);
13   ok(post instanceof DS.Model);
15   // set a relationship
16   Ember.run(function() {
17     post.set('comment', store.createRecord('comment', {}))
18   });
20   ok(post.get('comment'));
21   ok(post.get('comment') instanceof DS.Model);
22 });


The name of the model you are testing. It is necessary to only supply the name, not the resolver path to the object(model:post => post).


The description that will group all subsequent tests under. Defaults to the name.


You are able to supply custom setup, teardown, & subject functionality by passing them into the callbacks parameter. If other objects should be loaded into Ember.js, specify the objects through the needs property.

Note: If the model you are testing has relationships to any other model, those must be specified through the needs property.

this.store() retrieves the DS.Store.

this.subject() calls the factory for the DS.Model specified by the fullname and will return an instance of the object.

moduleForComponent(name, description, callbacks)

Extends the generic moduleFor with custom loading for testing components:

 1 import Ember from "ember";
 2 import { test, moduleForComponent } from 'ember-qunit';
 4 moduleForComponent('pretty-color');
 6 test('changing colors', function(){
 7   var component = this.subject();
 9   Ember.run(function(){
10     component.set('name','red');
11   });
13   // first call to $() renders the component.
14   equal(this.$().attr('style'), 'color: red;');
16   Ember.run(function(){
17     component.set('name', 'green');
18   });
20   equal(this.$().attr('style'), 'color: green;');
21 });


The name of the component you are testing. It is necessary to only supply the name, not the resolver path to the object(component:pretty-color => pretty-color).


The description that will group all subsequent tests under. Defaults to the name.


You are able to supply custom setup, teardown, & subject functionality by passing them into the callbacks parameter. If other objects should be loaded into Ember.js, specify the objects through the needs property.

this.subject() calls the factory for the Ember.Component specified by the fullname and will return an instance of the object.

The first call this.$() will render out the component. So if you want to test styling, you must access the component via jQuery.

Writing your own test helpers

Ember testing provides that ability to register your own test helpers. In order to use these with ember-cli they must be registered before startApp is defined.

Depending on your approach, you may want to define one helper per file or a group of helpers in one file.

Single helper per file

1 // helpers/routes-to.js
2 export default Ember.Test.registerAsyncHelper('routesTo', function (app, url, route_name) {
3   visit(url);
4   andThen(function () {
5     equal(currentRouteName(), route_name, 'Expected ' + route_name + ', got: ' + currentRouteName());
6   });
7 });

This can then be used in start-app.js, like this

1 // helpers/start-app.js
2 import routesTo from './routes-to';
4 export default function startApp(attrs) {
5 //...

Group of helpers in one file

An alternative approach is to create a bunch of helpers wrapped in a self calling function, like this

 1 // helpers/custom-helpers.js
 2 var customHelpers = function() {
 3   Ember.Test.registerHelper('myGreatHelper', function (app) {
 4     //do awesome test stuff
 5   });
 7   Ember.Test.registerAsyncHelper('myGreatAsyncHelper', function (app) {
 8     //do awesome test stuff
 9   });
10 }();
12 export default customHelpers;

which can be used in start-app.js

1 // helpers/start-app.js
2 import customHelpers from './custom-helpers';
4 export default function startApp(attrs) {
5 //...

Once your helpers are defined, you’ll want to ensure that they are listing in the .jshintrc file within the test directory.

1 // /tests/.jshintrc
2 {
3   "predef": [
4     "document",
5     //...
6     "myGreatHelper",
7     "myGreatAsyncHelper"

Asset Compilation

Raw Assets

  • public/assets vs app/styles

To add images, fonts, or other assets, place them in the public/assets folder. For example, if you place logo.png in public/assets/images, you can reference it in templates with /assets/images/logo.png or in stylesheets with url('/assets/images/logo.png').


The compiled css-files are minified by broccoli-clean-css or broccoli-csso, if it is installed locally. You can pass minifer-specific options to them using the minifyCSS:options object in your Brocfile. Minification is enabled by default in the production-env and can be disabled using the minifyCSS:enabled switch.

Similarly, the js-files are minified with broccoli-uglify-js in the production-env by default. You can pass custom options to the minifier via the minifyJS:options object in your Brocfile. To enable or disable JS minification you may supply a boolean value for minifyJS:enabled.


Ember CLI supports plain CSS out of the box. You can add your css styles to app/styles/app.css and it will be served at assets/application-name.css.

For example, to add bootstrap in your project you need to do the following:

bower install --save-dev bootstrap

In Brocfile.js add the following:


it’s going to tell Broccoli that we want this file to be concatenated with our vendor.css file.

To use a CSS preprocessor, you’ll need to install the appropriate Broccoli plugin. When using a preprocessor, Broccoli is configured to look for an app.less, app.scss, app.sass, or app.styl manifest file in app/styles. This manifest should import any additional stylesheets.

All your preprocessed stylesheets will be compiled into one file and served at assets/application-name.css.

If you would like to change this behavior, or compile to multiple output stylesheets, you can adjust the Output Paths Configuration


  • Relative pathing gets changed (how to customize?)
  • @import statements -> concat

To use one of the following preprocessors, all you need to do is install the appropriate NPM module. The respective files will be picked up and processed automatically.


To enable LESS, you’ll need to add ember-cli-less to your NPM modules.

npm install --save-dev ember-cli-less


To enable Sass, you’ll need to add broccoli-sass to your NPM modules (both .scss/.sass are allowed as of broccoli-sass > 0.2.0).

npm install --save-dev broccoli-sass


To use Compass with your ember-cli app, install ember-cli-compass-compiler addon using NPM.

npm install --save-dev ember-cli-compass-compiler


To enable Stylus, you must first add ember-cli-stylus to your NPM modules:

npm install --save-dev ember-cli-stylus


To enable CoffeeScript, you must first add ember-cli-coffeescript to your NPM modules:

npm install --save-dev ember-cli-coffeescript

The modified package.json should be checked into source control. CoffeeScript can be used in your app’s source and in tests, just use the .coffee extension on any file.

The ES6 module transpiler does not directly support CoffeeScript, but using them together is simple. Use the ` character to escape out to JavaScript from your .coffee files, and use the ES6 syntax there:

1 # app/models/post.coffee
2 `import Ember from 'ember'`
3 `import User from 'appkit/models/user'`
5 Post = Ember.Object.extend
6   init: (userId) ->
7     @set 'user', User.findById(userId)
9 `export default Post`

Note that earlier versions of the transpiler had explicit support for CoffeeScript, but that support has been removed.


To enable EmberScript, you must first add broccoli-ember-script to your NPM modules:

npm install --save-dev broccoli-ember-script

Note that the ES6 module transpiler is not directly supported with Emberscript, to allow use of ES6 modules use the ` character to escape raw Javascript similar to the CoffeeScript example above.


For Emblem, run the following commands:

npm install --save-dev broccoli-emblem-compiler

Fingerprinting and CDN URLs

Fingerprinting is done using the addon broccoli-asset-rev (which is included by default).

When the environment is production (e.g. ember build --environment=production), the addon will automatically fingerprint your js, css, png, jpg, and gif assets by appending an md5 checksum to the end of their filename (e.g. assets/yourapp-9c2cbd818d09a4a742406c6cb8219b3b.js). In addition, your html, js, and css files will be re-written to include the new name. There are a few options you can pass in to EmberApp in your Brocfile.js to customize this behavior.

  • enabled - Default: app.env === 'production' - Boolean. Enables fingerprinting if true. True by default if current environment is production.
  • exclude - Default: [] - An array of strings. If a filename contains any item in the exclude array, it will not be fingerprinted.
  • extensions - Default: ['js', 'css', 'png', 'jpg', 'gif'] - The file types to add md5 checksums.
  • prepend - Default: '' - A string to prepend to all of the assets. Useful for CDN urls like https://subdomain.cloudfront.net/
  • replaceExtensions - Default: ['html', 'css', 'js'] - The file types to replace source code with new checksum file names.

As an example, this Brocfile will exclude any file in the fonts/169929 directory as well as add a cloudfront domain to each fingerprinted asset.

1 var app = new EmberApp({
2   fingerprint: {
3     exclude: ['fonts/169929'],
4     prepend: 'https://sudomain.cloudfront.net/'
5   }
6 });

The end result will turn

<script src="assets/appname.js">
background: url('/images/foo.png');


<script src="https://subdomain.cloudfront.net/assets/appname-342b0f87ea609e6d349c7925d86bd597.js">
background: url('https://subdomain.cloudfront.net/images/foo-735d6c098496507e26bb40ecc8c1394d.png');

You can disable fingerprinting in your Brocfile.js:

var app = new EmberApp({
  fingerprint: {
    enabled: false

Or remove the entry from your EmberApp and broccoli-asset-rev from your package.json.

Application Configuration

Application configurations from your Brocfile.js will be stored inside a special meta tag in dist/index.html.

sample meta tag:

<meta name="user/config/environment" content="%7B%22modulePre.your.config">

This meta tag is required for your ember application to function properly. If you prefer to have this tag be part of your compiled javascript files instead, you may use the storeConfigInMeta flag.

var app = new EmberApp({
  storeConfigInMeta: false

Configuring output paths

The compiled files are output to the following paths:

Assets Output File
app/index.html /index.html
app/*.js /assets/application-name.js
app/styles/app.css /assets/application-name.css
other CSS files in app/styles same filename in /assets
JavaScript files you import with app.import() /assets/vendor.js
CSS files you import with app.import() /assets/vendor.css

To change these paths you can edit the outputPaths config option. The default setting is shown here:

var app = new EmberApp({
  outputPaths: {
    app: {
      html: 'index.html'
      css: {
        'app': '/assets/application-name.css'
      js: '/assets/application-name.js'
    vendor: {
      css: '/assets/vendor.css',
      js: '/assets/vendor.js'

You may edit any of these output paths, but make sure to update your app.outputPaths.app.index, default it is index.html, and tests/index.html.

var app = new EmberApp({
  outputPaths: {
    app: {
      js: '/assets/main.js'

The outputPaths.app.css option uses a key value relationship. The key is the input file and the value is the output location. Note that we do not include the extension for the input path, because each preprocessor has a different extension.

When using CSS preprocessing, only the app/styles/app.scss (or .less etc) is compiled. If you need to process multiple files, you must add another key:

var app = new EmberApp({
  outputPaths: {
    app: {
      css: {
        'app': '/assets/application-name.css',
        'themes/alpha': '/assets/themes/alpha.css'

Managing Dependencies

Ember CLI uses Bower for dependency management.

Bower Configuration

The Bower configuration file, bower.json, is located at the root of your Ember CLI project, and lists the dependencies for your project. Changes to your dependencies should be managed through this file, rather than manually installing packages individually.

Executing bower install will install all of the dependencies listed in bower.json in one step.

Ember CLI is configured to have git ignore your bower_components directory by default. Using the Bower configuration file allows collaborators to fork your repo and get their dependencies installed locally by executing bower install themselves.

Ember CLI watches bower.json for changes. Thus it reloads your app if you install new dependencies via bower install --save <dependencies>.

Further documentation about Bower is available at their official documentation page.

Compiling Assets

In your Brocfile.js specify a dependency before calling app.toTree(). You can only import assets that are within the bower_components or vendor directories. The following example scenarios illustrate how this works.

Javascript Assets

Standard Non-AMD Asset

Provide the asset path as the first and only argument:

1 app.import('bower_components/moment/moment.js');

From here you would use the package as specified by it’s documentation, usually a global variable. In this case it would be:

1 import Ember from 'ember';
2 /* global moment */
3 // No import for moment, it's a global called `moment`
5 // ...
6 var day = moment('Dec 25, 1995');

Note: Don’t forget to make JSHint happy by adding a /* global MY_GLOBAL */ to your module, or by defining it within the predefs section of your .jshintrc file.

Standard AMD Asset

Provide the asset path as the first argument, and the list of modules and exports as the second:

 1 app.import('bower_components/ic-ajax/dist/named-amd/main.js', {
 2   exports: {
 3     'ic-ajax': [
 4       'default',
 5       'defineFixture',
 6       'lookupFixture',
 7       'raw',
 8       'request',
 9     ]
10   }
11 });

To use this asset in your app, import it. For example, with ic-ajax, when to use ic.ajax.raw:

1 import { raw as icAjaxRaw } from 'ic-ajax';
2 //...
3 icAjaxRaw( /* ... */ );
Environment Specific Assets

If you need to use different assets in different environments, specify an object as the first parameter. That object’s key should be the environment name, and the value should be the asset to use in that environment.

1 app.import({
2   development: 'bower_components/ember/ember.js',
3   production:  'bower_components/ember/ember.prod.js'
4 });

If you need to import an asset in one environment but not import it or any alternatives in other environments then you can wrap app.import in an if statement.

1 if (app.env === 'development') {
2   app.import('vendor/ember-renderspeed/ember-renderspeed.js');
3 }
Customizing a built-in Asset

This is somewhat non-standard and discouraged, but suppose that due to a requirement in your application that you need to use the full version of Handlebars even in the production environment. You would simply provide the path to the EmberApp constructor:

1 var app = new EmberApp({
2   vendorFiles: {
3     'handlebars.js': {
4       production: 'bower_components/handlebars/handlebars.js'
5     }
6   }
7 });

Alternatively, if you want to exclude the built-in asset from being automatically included in vendor.js, you can set its value to false:

1 var app = new EmberApp({
2   vendorFiles: {
3     'handlebars.js': false
4   }
5 });

Note: The built-in assets are required dependencies needed by the environment to run your app. If you use the above method to specifically exclude some, you should still be including them in some other way.

Test Assets

You may have additional libraries that should only be included when running tests (such as qunit-bdd or sinon). These can be imported into your app in your Brocfile.js:

 1 var EmberApp = require('ember-cli/lib/broccoli/ember-app'),
 2     isProduction = ( process.env.EMBER_ENV || 'development' ) === 'production';
 4 var app = new EmberApp();
 6 if ( !isProduction ) {
 7     app.import( app.bowerDirectory + '/sinonjs/sinon.js', { type: 'test' } );
 8     app.import( app.bowerDirectory + '/sinon-qunit/lib/sinon-qunit.js', { type: 'test' } );
 9 }
11 module.exports = app.toTree();

Notes: - Be sure to pass { type: 'test' } as the second argument to app.import. This will ensure that your libraries are compiled into the test-support.js file.


Static CSS

Provide the asset path as the first argument:

1 app.import('bower_components/foundation/css/foundation.css');

All style assets added this way will be concatenated and output as /assets/vendor.css.

Dynamic Styles (SCSS, LESS, etc)

The vendor trees that are provided upon instantiation are available to your dynamic style files. Take the following example (in app/styles/app.scss):

1 @import "bower_components/foundation/scss/normalize.scss";

Other Assets

Using app.import()

All other assets like images or fonts can also be added via import(). By default, they will be copied to dist/ as they are.

1 app.import('bower_components/font-awesome/fonts/fontawesome-webfont.ttf');

This example would create the font file in dist/font-awesome/fonts/fontawesome-webfont.ttf.

You can also optionally tell import() to place the file at a different path. The following example will copy the file to dist/assets/fontawesome-webfont.ttf.

1 app.import('bower_components/font-awesome/fonts/fontawesome-webfont.ttf', {
2   destDir: 'assets'
3 });
Using broccoli-static-compiler

With the broccoli-static-compiler package, (parts of) a bower-installed package can be used as assets as-is. First ensure that the Broccoli package needed to build are installed:

npm install --save-dev broccoli-static-compiler

Add this import to the top of Brocfile.js, just below the EmberApp require:

1 var pickFiles = require('broccoli-static-compiler');

At the bottom of Brocfile.js we merge assets from a bower dependency with the main app tree:

 1 // Remove this line:
 2 // module.exports = app.toTree()
 4 // Copy only the relevant files. For example the WOFF-files and stylesheets for a webfont:
 5 var extraAssets = pickFiles('bower_components/a-lovely-webfont', {
 6    srcDir: '/',
 7    files: ['**/*.woff', '**/stylesheet.css'],
 8    destDir: '/assets/fonts'
 9 });
11 // Providing additional trees to the `toTree` method will result in those
12 // trees being merged in the final output.
13 module.exports = app.toTree(extraAssets);

In the above example the assets from the fictive bower dependency called a-lovely-webfont can now be found under /assets/fonts/, and might be linked to from index.html like so:

<link rel="stylesheet" href="assets/fonts/lovelyfont_bold/stylesheet.css">

Generators & Blueprints


Ember CLI ships with “Blueprints”, snippet generators for many of the entities - models, controllers, components, and so on - that you’ll need in your app. Blueprints allow us to share common Ember patterns in the community and you can even define your own.

To see a list of all available blueprints, with a short description of what they do, run ember generate --help or ember g --help, for short, at any time. For a longer, more detailed description of each blueprint, look in the appendix to this guide.

Generating Blueprints

This in an example of how to generate a Route Blueprint.

ember generate route foo

  create app/routes/foo.js
  create app/templates/foo.hbs
  create tests/unit/routes/foo-test.js

For a list of all available blueprints, run:

ember help generate

Defining a Custom Blueprint

You can define your own blueprints using ember generate blueprint <name>:

ember generate blueprint foo

  create blueprints/.jshintrc
  create blueprints/foo/files/.gitkeep
  create blueprints/foo/index.js

Blueprints in your project’s directory take precedence over those packaged with ember-cli. This makes it easy to override the built-in blueprints just by generating one with the same name.


You can generate certain built-in blueprints with a pods structure by passing the --pod option.

ember generate route foo --pod

  create app/foo/route.js
  create app/foo/template.hbs
  create tests/unit/foo/route-test.js

If you have podModulePrefix defined in your environment, your generated pod path will be automatically prefixed with it.

// podModulePrefix: app/pods
ember generate route foo --pod

  create app/pods/foo/route.js
  create app/pods/foo/template.hbs
  create tests/unit/pods/foo/route-test.js

The built-in blueprints that support pods structure are:

  • adapter
  • component
  • controller
  • model
  • route
  • resource
  • serializer
  • template
  • transform
  • view

Blueprints that don’t support pods structure will simply ignore the --pod option and use the default structure.

If you would like to use the pods structure as the default for your project, you can set usePodsByDefault in your environment config to true. When usePodsByDefault is true, the --pod flag is essentially inverted. To generate or destroy a blueprint in the default type structure while usePodsByDefault is true, use the --pod flag.

With the usePodsByDefault set to true.

 1 // config/environment.js
 2 module.exports = function(environment) {
 3   var ENV = {
 4     modulePrefix: 'my-new-app',
 5     podModulePrefix: 'my-new-app/pods'
 6     usePodsByDefault: true,
 7     environment: environment,
 8     baseURL: '/',
 9     locationType: 'auto',
10 //...

The following would occur when generating a route:

ember generate route taco

  create app/taco/route.js
  create app/taco/template.hbs
  create tests/unit/taco/route-test.js

ember generate route taco --pod

  create app/routes/taco.js
  create app/templates/taco.hbs
  create tests/unit/routes/taco-test.js

Blueprint Structure

Blueprints follow a simple structure. Let’s take the built-in helper blueprint as an example:

  ├── files
  │   ├── app
  │   │   └── helpers
  │   │       └── __name__.js
  └── index.js

The accompanying test is in another blueprint. Because it has the same name with a -test suffix, it is generated automatically with the helper blueprint in this case.

  ├── files
  │   └── tests
  │       └── unit
  │           └── helpers
  │               └── __name__-test.js
  └── index.js

Blueprints that support pods structure look a little different. Let’s take the built-in controller blueprint as an example:

  ├── files
  │   ├── app
  │   │   └── __path__
  │   │       └── __name__.js
  └── index.js

  ├── files
  │   └── tests
  │       └── unit
  │           └── __path__
  │               └── __test__.js
  └── index.js


files contains templates for the all the files to be installed into the target directory.

The __name__ token is subtituted with the dasherized entity name at install time. For example, when the user invokes ember generate controller foo then __name__ becomes foo. When the --pod flag is used, for example ember generate controller foo --pod then __name__ becomes controller.

The __path__ token is substituted with the blueprint name at install time. For example, when the user invokes ember generate controller foo then __path__ becomes controller. When the --pod flag is used, for example ember generate controller foo --pod then __path__ becomes foo (or <podModulePrefix>/foo if the podModulePrefix is defined). This token is primarily for pod support, and is only necessary if the blueprint can be used in pod structure. If the blueprint does not require pod support, simply use the blueprint name instead of the __path__ token.

The __test__ token is substituted with the dasherized entity name and appended with -test at install time. This token is primarily for pod support and only necessary if the blueprint requires support for a pod structure. If the blueprint does not require pod support, simply use the __name__ token instead.

Template Variables (AKA Locals)

Variables can be inserted into templates with <%= someVariableName %>.

For example, the built-in util blueprint files/app/utils/__name__.js looks like this:

1 export default function <%= camelizedModuleName %>() {
2   return true;
3 }

<%= camelizedModuleName %> is replaced with the real value at install time.

The following template variables are provided by default:

  • dasherizedPackageName
  • classifiedPackageName
  • dasherizedModuleName
  • classifiedModuleName
  • camelizedModuleName

packageName is the project name as found in the project’s package.json.

moduleName is the name of the entity being generated.

The mechanism for providing custom template variables is described below.


Custom installation and uninstallation behaviour can be added by overriding the hooks documented below. index.js should export a plain object, which will extend the prototype of the Blueprint class. If needed, the original Blueprint prototype can be accessed through the _super property.

 1 module.exports = {
 2   locals: function(options) {
 3     // Return custom template variables here.
 4     return {};
 5   },
 7   normalizeEntityName: function(entityName) {
 8     // Normalize and validate entity name here.
 9     return entityName;
10   },
12   fileMapTokens: function(options) {
13     // Return custom tokens to be replaced in your files
14     return {
15       __token__: function(options){
16         // logic to determine value goes here
17         return 'value';
18       }
19     }
20   },
22   beforeInstall: function(options) {},
23   afterInstall: function(options) {},
24   beforeUninstall: function(options) {},
25   afterUninstall: function(options) {}
27 };

Blueprint Hooks

As shown above, the following hooks are available to blueprint authors:

  • locals
  • normalizeEntityName
  • fileMapTokens
  • beforeInstall
  • afterInstall
  • beforeUninstall
  • afterUninstall


Use locals to add custom tempate variables. The method receives one argument: options. Options is an object containing general and entity-specific options.

When the following is called on the command line:

ember generate controller foo --type=array --dry-run

The object passed to locals looks like this:

1 {
2   entity: {
3     name: 'foo',
4     options: {
5       type: 'array'
6     }
7   },
8   dryRun: true
9 }

This hook must return an object. It will be merged with the aforementioned default locals.


Use the normalizeEntityName hook to add custom normalization and validation of the provided entity name. The default hook does not make any changes to the entity name, but makes sure an entity name is present and that it doesn’t have a trailing slash.

This hook receives the entity name as its first argument. The string returned by this hook will be used as the new entity name.


Use fileMapTokens to add custom fileMap tokens for use in the mapFile method. The hook must return an object in the following pattern:

1 {
2   __token__: function(options){
3     // logic to determine value goes here
4     return 'value';
5   }
6 }

It will be merged with the default fileMapTokens, and can be used to override any of the default tokens.

Tokens are used in the files folder (see files), and get replaced with values when the mapFile method is called.

beforeInstall & beforeUninstall

Called before any of the template files are processed and receives the same arguments as locals. Typically used for validating any additional command line options.

afterInstall & afterUninstall

The afterInstall and afterUninstall hooks receives the same arguments as locals. Use it to perform any custom work after the files are processed. For example, the built-in route blueprint uses these hooks to add and remove relevant route declarations in app/router.js.

Overriding Install

If you don’t want your blueprint to install the contents of files you can override the install method. It receives the same options object described above and must return a promise. See the built-in resource blueprint for an example of this.


Detailed List of Blueprints and Their Use

  • Acceptance Test
    • Generates an acceptance test for a given feature
    • Acceptance Tests are used to test flows within your application i.e. a signup, login, editing your account, etc.
    • ember generate acceptance-test signup
  • Adapter
    • This blueprint generates an Ember Data Adapter and its accompanying test
    • Options
      • Base Class
        • Application (default)
    • ember generate adapter application will generate an adapter called ‘ApplicationAdapter’ based off the DS.RESTAdapter by default.
    • ember generate adapter user will in turn call this adapter UserAdapter and inherit from the Application Adapter unless you specify a base class.
  • Adapter Test
    • This blueprint generates a unit test for a given ember data adapter.
    • ember generate adapter-test application
  • Addon
    • Generates an addon blueprint and its definition.
      • This is the base blueprint for ember-cli addons.
    • ember generate addon awesome-addon
  • App
    • This is the default blueprint for ember-cli projects. It contains a conventional project structure and everything you will need to develop your ember apps.
    • This blueprint is most commonly encountered when starting a new application, as in ember new.
  • Blueprint
    • Generates a Blueprint and its corresponding definition. You can use this to create your own custom Blueprints. A Blueprint is essentially a bundle of templates with optional install logic.
    • ember generate blueprint example-blueprint
  • Component
    • Generates an Ember Component and its accompanying test.
    • A Component is your own app-specific tag with custom behaviour. They are basically views that are completely isolated. Usually used for building widgets.
    • Caveats
      • The component’s name must contain a hyphen
      • Slashes are not allowed
    • ember generate component nav-bar
  • Component Test
    • Generates a test for a given component
    • ember generate component-test nav-bar
  • Controller
    • Generates a Controller of a given name, with accompanying test.
    • ember generate controller users
  • Controller Test
    • Generates a unit test for a given Controller.
  • Helper
    • Generates a Handlebars Helper and its test. Commonly used for html reuse.
    • ember generate helper capitalize
  • Helper Test
    • Generates a test for a given helper
    • ember generate helper-test capitalize
  • HTTP Mock
    • This blueprint generates a mock endpoint with an ‘/api’ prefix that you can use to return canned data. This is commonly used as an API stub, which allows you to develop right away with the RESTAdapter instead of using fixtures.
    • ember generate http-mock users
  • HTTP Proxy
    • Generates a relative proxy to another server. You can use this to forward requests to a local development server, for example.
    • Options
      • Local Path
      • Remote URL
    • ember generate http-proxy
  • In-Repo Addon
    • Generates an addon within the same repository. Useful for project-specific addons.
    • The generator also creates a ‘lib’ folder, in which it stores the new addon.
    • ember generate in-repo-addon calendar
  • Initializer
    • Generates an Ember Initializer and its accompanying tests.
    • Common uses are to setup injection rules, like a current user, services, etc. You shouldn’t use them for fetching data via XHR, deferring readiness, or instantiating and using ‘container.lookup’. For more about initializers, view the API docs
    • ember generate initializer current-user
  • Initializer Test
    • Generates a test for a given initializer.
    • ember generate initializer-test current-user
  • Mixin
    • Generates a Mixin and its test. A mixin is an object whose properties can be added to other classes, like Controllers, Views, Routes, etc.
    • ember generate mixin filterable
  • Mixin Test
    • Generates a test for a given mixin.
    • ember generate mixin-test filterable
  • Model
    • Generates an Ember Data model and its test.
    • ember generate model user
  • Model Test
    • Generates a test for a given model.
    • ember generate model-test user
  • Resource
    • This blueprint generates a model, route, template, and their accompanying tests.
    • ember generate resource user
  • Route
    • Generates a route, its test, and then registers it with the router.
    • Type
      • Route (default)
      • Resource
    • ember generate route user
  • Route Test
    • Generates a test for a given route.
  • Serializer
    • Generates an Ember Data serializer.
    • ember generate serializer application
  • Serializer Test
    • Generates a test for a given ember data serializer
    • ember generate serializer-test application
  • Service
    • Generates a service and initializer for injections. These are commonly used for cases like websocket initialization, geolocation, feature flags, etc.
    • ember generate service geolocation
  • Service Test
    • Generates a unit test for a given service.
    • ember generate service-test geolocation
  • Template
    • Generates a template.
    • ember generate template user
  • Transform
    • Generates an Ember Data value transform, which are used to serialize and deserialize model attributes as they saved and loaded from the adapter. These can be useful for creating custom attributes.
    • ember generate transform foo
  • Transform Test
    • Generates a transform unit test.
    • ember generate transform-test foo
  • Util
    • Generates a utility module/function.
    • ember generate util foo
  • Util Test
    • Generates a util unit test.
    • ember generate util-test foo
  • View
    • Generates a View.
    • ember generate view user
  • View Test
    • Generates a view unit test.
    • ember generate view-test user

Developing Addons and Blueprints

Addons make it possible to easily share common code between applications.

This guide will walk through the development cycle of a fictional addon ember-cli-x-button.


An addon can be installed like any other npm package:

npm install --save-dev <package name>

To install the (fictional) x-button addon package:

npm install --save-dev ember-cli-x-button


Ember CLI will detect the presence of an addon by inspecting each of your applications dependencies and search their package.json files for the presence of ember-addon in the keywords section (see below).

"keywords": [

Addon scenarios

The Ember CLI addons API currently supports the following scenarios:

  • Performing operations on the EmberApp created in the consuming application’s Brocfile.js
  • Adding preprocessors to the default registry
  • Providing a custom application tree to be merged with the consuming application
  • Providing custom express (server) middlewares
  • Adding custom/extra blueprints, typically for scaffolding application/project files
  • Adding content to consuming applications

Addon CLI options

Ember CLI has an addon command with some options:

ember addon <addon-name> <options...>

Note: An addon can NOT be created inside an existing application.

Create addon

To create a basic addon:

Running this command should generate something like the following:

ember addon my-x-button
version x.y.zz
  create .bowerrc
  create .editorconfig
  create tests/dummy/.jshintrc
  create index.js

Installing packages for tooling via npm
Installed browser packages via Bower.

Addon conventions

The addon infrastructure is based on “convention over configuration” in accordance with the Ember philosophy. You are encouraged to follow these conventions to make it easier on yourself and for others to better understand your code. The same applies for addon blueprints.

Addon project structure

The addon project created follows these structure conventions:

  • app/ - merged with the application’s namespace.
  • addon/ - part of the addon’s namespace.
  • blueprints/ - contains any blueprints that come with the addon, each in a separate folder
  • tests/ - test infrastructure including a “dummy” app and acceptance test helpers.
  • vendor/ - vendor specific files, such as stylesheets, fonts, external libs etc.
  • Brocfile.js - Compilation configuration
  • package.json - Node meta-data, dependencies etc.
  • index.js - main Node entry point (as per npm conventions)


The generated addon package.json file looks something like this:

  "name": "ember-cli-x-button", // addon name
  "version": "0.0.1", // version of addon
  "directories": {
    "doc": "doc",
    "test": "test"
  "scripts": {
    "start": "ember server",
    "build": "ember build",
    "test": "ember test"
  "repository": "https://github.com/repo-user/my-addon",
  "engines": {
    "node": ">= 0.10.0"
  "keywords": [
    // add more keywords to better categorize the addon
  "ember-addon": {
    // addon configuration properties
    "configPath": "tests/dummy/config"
  "author": "", // your name
  "license": "MIT", // license
  "devDependencies": {
    "body-parser": "^1.2.0",
    ... // add specific dev dependencies here!

Let’s add some meta data to categorize the addon a little better:

"keywords": [

Addon entry point

An addon will leverage the npm conventions, and look for an index.js as the entry point unless another entry point is specified via the "main" property in the package.json file. You are encouraged to use index.js as the addon entry point.

The generated index.js is a simple JavaScript Object (POJO) that you can customize and expand as you see fit.

// index.js
module.exports = {
  name: 'my-addon'

During the build process, the included hook on your addon will be called, allowing you to perform setup logic or modify the app or including addon:

// index.js
module.exports = {
  name: 'my-addon',
  included: function(app, parentAddon) {
    var target = (parentAddon || app);
    // Now you can modify the app / parentAddon. For example, if you wanted
    // to include a custom preprocessor, you could add it to the target's
    // registry:
    //     target.registry.add('js', myPreprocessor);

Configuring your ember-addon properties

By default, the "ember-addon" hash in the package.json file has the "configPath" property defined to point to the config directory of the test dummy application.

Optionally, you may specify whether your ember-addon must run "before" or "after" any other Ember CLI addons. Both of these properties can take either a string or an array of strings, where the string is the name of the another Ember CLI addon, as defined in the package.json of the other addon.

"ember-addon": {
  // addon configuration properties
  "configPath": "tests/dummy/config",
  "before": "single-addon",
  "after": [

Managing addon dependencies

Install your client side dependencies via Bower. Here we install a fictional bower dependency x-button:

bower install --save-dev x-button

Adds bower components to development dependencies

// bower.js
  "name": "ember-x-button",
  "dependencies": {
    // ...
  "devDependencies": {
    "x-button":  "^1.4.0"

Addon Brocfile

The addon’s Brocfile.js is only used to configure the dummy application found in tests/dummy/. It is never referenced by applications which include the addon.

If you need to use Brocfile.js, you may have to specify paths relative to the addon root directory. For example to configure ember-cli-less to use app.less in the dummy app:

// Brocfile.js
var EmberAddon = require('ember-cli/lib/broccoli/ember-addon');

var app = new EmberAddon({
  lessOptions: {
    paths: ['tests/dummy/app/styles/'],
    outputFile: 'dummy.css'

module.exports = app.toTree();


The actual code for the addon goes in addon/components/x-button.js

import Ember from 'ember';

export default Ember.Component.extend({
  tagName: 'button',

  setupXbutton: function() {
    // ...

  teardownXbutton: function() {

In order to allow the consuming application to use the addon component without manual import statements, put the component under the app/components directory.

// app/components/x-button.js

import Ember from 'ember';
import XButton from 'ember-x-button/components/x-button';

export default XButton;

The code imports the component from the addon directory and exports it again. This setup allows others to modify the component by extending it while making the component available in the consuming applications namespace. This means anyone who installs your x-button addon can start using the component in their templates with `` without any extra configuration.


To create a blueprint, add a file blueprints/x-button/index.js. This follows the usual Ember blueprints naming conventions.

Make sure the dependency files are imported into the consuming application. Use the included hook to import the files in the correct order.

We want to register a no-op package in bower called x-button. Consume it as x-button: 0.0.1. Import x-button/dist/js/x-button.js and x-button/dist/css/x-button.css.

module.exports = {
  name: 'ember-cli-x-button',

  included: function(app) {

    app.import(app.bowerDirectory + '/x-button/dist/js/x-button.js');
    app.import(app.bowerDirectory + '/x-button/dist/css/x-button.css');

In the example file, the included hook is used. This hook is called by the EmberApp constructor and gives access to the consuming application as app. When the consuming application’s Brocfile.js is processed by Ember CLI to build/serve, the addon’s included function is called passing the EmberApp instance.


If you want to add content to a page directly, you can use the content-for tag. An example of this is {{content-for 'head'}} in app/index.html, which Ember CLI uses to insert it’s own content at build time. Addons can access the contentFor hook to insert their own content.

module.exports = {
  name: 'ember-cli-display-environment',

  contentFor: function(type, config) {
    if (type === 'environment') {
      return '<h1>' + config.environment + '</h1>';

This will insert the current environment the app is running under wherever {{content-for 'environment'}} is placed. The contentFor function will be called for each {{content-for}} tag in index.html.

Advanced customization

If you want to go beyond the built in customizations or want/need more advanced control in general, the following are some of the hooks (keys) available for your addon Object in the index.js file. All hooks expect a function as the value.

includedCommands: function() {},
blueprintsPath: // return path as String

An example of advanced customization can be found here and for server middleware here

Testing the addon with QUnit

The addon project contains a /tests folder which contains the necessary infrastructure to run and configure tests for the addon. The /tests folder has the following structure:


The /dummy folder contains the basic layout of a dummy app to be used for to host your addon for testing. The /helpers folder contains various QUnit helpers that are provided and those you define yourself in order to keep your tests concise. The /unit folder should contain your unit tests that test your addon in various usage scenarios. To add integration (acceptance) tests add an `integration/’ folder.

test-helper.js is the main helper file that you should reference from any of your unit test files. It imports the resolver helper found in /helpers used to resolve pages in the dummy app. index.html contains the test page that you can load in a browser to display the results of running your integration tests.

Writing acceptance tests

The following is an example of a simple QUnit acceptance test, placed in tests/unit/components.

// tests/unit/components/button-test.js

import { test, moduleForComponent } from 'ember-qunit';
import startApp from '../../helpers/start-app';
import Ember from 'ember';

var App;

moduleForComponent('x-button', 'XButtonComponent', {
  setup: function() {
    App = startApp();
  teardown: function() {
    Ember.run(App, 'destroy');

test('is a button tag', function() {
  equal('BUTTON', this.$().prop('tagName'));


// more tests follow...

For how to run and configure tests, see the Ember CLI Testing section.

Create blueprint

A blueprint is a bundle of template files with optional installation logic. It is used to scaffold (generate) specific application files based on some arguments and options. For more details see generators-and-blueprints). An addon can have one or more blueprints.

To create a blueprint for your addon:

ember addon <blueprint-name> --blueprint

By convention, the main blueprint of the addon should have the same name as the addon itself:

ember addon <addon-name> --blueprint

In our example:

ember addon x-button --blueprint

This will generate a folder blueprints/x-button for the addon where you can define your logic and templates for the blueprint. You can define multiple blueprints for a single addon. The last loaded blueprint wins with respect to overriding existing (same name) blueprints that come with Ember or other addons (according to package load order.)

Blueprint conventions

Blueprints are expected to be located under the blueprints folder in the addon root, just like blueprints overrides in your project root.

If you have your blueprints in another folder in your addon, you need to tell ember-cli where to find them by specifying a blueprintsPath property for the addon (see advanced customization section below).

If you are familiar with Yeoman (or Rails) generators, blueprints follow very similar conventions and structure.

To dive deeper into blueprints design, please see the Ember CLI blueprints where you get a feeling for the blueprints API.

Blueprints file structure


Note that the special file or folder called __name__ will create a file/folder at that location in your app with the __name__ replaced by the first argument (name) you pass to the blueprint being generated.

ember g x-button my-button

Will thus generate a folder app/components/my-button in the application where the blueprint generator is run.

While you are developing and testing, you can run npm link from the root of your addon project. This will make your addon locally available by name.

Then run npm link <addon-name> in any hosting application project root to make a link to your addon in your node_modules folder. Any change in your addon will now directly take effect in any project that links to it this way (see npm-tricks for more details).

While testing an addon using npm link, you need an entry in package.json with your addon name, with any valid npm version: "<addon-name>":"version". Our fictional example would require "x-button": "*". You can now run ember g <addon-name> in your project.

Publish addon

Use npm and git to publish the addon like a normal npm package.

npm version 0.0.1
git push origin master
git push origin --tags
npm publish

Using a private repository

You can upload your addon code to a private git repository and call npm install with a valid git URL as the version.

If you are using bitbucket.org the URL formats can be found here.

When using the git+ssh format, the npm install command will require there to be an available ssh key with read access to the reposirtory. This can be tested by running git clone ssh://git@github.com:user/project.git.

When using the git+https format, the npm install command will ask you for the account password.

Install and use addon

In order to use the addon from you hosting application:

To install your addon from the npm.org repository:

npm install ember-cli-<your-addon-name-here> --save-dev.

For our x-button sample addon:

npm install ember-cli-x-button --save-dev.

Run the x-button blueprint generator via:

ember generate x-button

Updating addons

You can update an addon the same way you update an Ember app by running ember init in your project root.

Full example

For a good walkthrough of the (recent) development of a real world addon, take a look at: Creating a DatePicker Ember CLI addon


Ember-CLI ships with support for managing your application’s environment. By default, Ember-CLI will build an environment config file at config/environment. Here, you can define an ENV object for each environment (development and production by default).

The ENV object contains two important keys: 1) EmberENV, and 2) APP. The first can be used to define Ember feature flags (see the Feature Flags guide). The second can be used to pass flags/options to your application instance.

You can access these environment variables in your application code by importing from ../config/environment or your-application-name/config/environment.

For example:

1 import ENV from 'your-application-name/config/environment';
3 if (ENV.environment === 'development') {
4   // ...
5 }

Ember-CLI assigns ENV.EmberENV to window.EmberENV, which Ember reads on application initialization.

Additionally, Ember-CLI contains a number of environment-dependent helpers for assets:

It is now also possible to override command line options by creating a file in your app’s root directory called .ember-cli and placing desired overrides in it.

For example, a common desire is to change the port that ember-cli serves the app from. It’s possible to pass the port number directly to ember server in the command line, e.g. ember serve --port 8080. If you wish to make this change a permanent configuration change, make the .ember-cli file and add the options you wish to pass to the server in a hash.

  "port": 8080


You can easily deploy your Ember CLI application to a number of places.



Change directories to your Ember CLI application’s. Now, create your new Heroku application with the Ember CLI buildpack…

heroku create <OPTIONAL_APP_NAME> --buildpack https://github.com/tonycoco/heroku-buildpack-ember-cli.git

You should be able to now deploy your Ember CLI application with Heroku’s git hooks…

git commit -am "Empty commit for Heroku deployment" --allow-empty
git push heroku master

Need to make a custom nginx configuration change? No problem. In your Ember CLI application, add a config/nginx.conf.erb file. You can copy the existing configuration file and make your changes to it.

History API and Base URL

If you are deploying the app to somewhere other than the root URL (/), you will need to configure the value of baseUrl in config/environment.js. For example

1 // config/environment.js
2   if (environment === 'production') {
3     ENV.baseURL = '/path/to/ember/app/';

This value is used to set the value of base in index.html, e.g. <base href="/path/to/ember/app/" />, as this is required for the History API, and thus also the Router, to function correctly.

Content security policy

To enable the Content Security Policy on your production stack, you’ll need to copy the Content-Security-Policy and X-Content-Security-Policy (for IE) from the headers generated by ember serve. If you’d like to enable it in report-only mode, use Content-Security-Policy-Report-Only and X-Content-Security-Policy-Report-Only. Make sure you’ve set a report-uri if you enable the CSP in report-only mode.

Deploying an HTTPS server using Nginx on a Unix/Linux/MacOSx machine

The following is a simple deployment with https using nginx. Http just redirects to the https server here. Don’t forget to include your ssl keys in your config.

Before deployment make sure you run this command to populate the dist directory:

ember build --environment="production"

File: nginx.conf

## Nginx Production Https Ember Server Configuration

## https site##
server {
    listen      443 default;
    server_name <your-server-name>;
    #root        /usr/share/nginx/html;
    root        <root path to an ember /dist directory>;
    index       index.html index.htm;

    # log files
    access_log  /var/log/nginx/<your-server-name>.access.log;
    error_log   /var/log/nginx/<your-server-name>.error.log;

    # ssl files
    ssl on;
    keepalive_timeout   60;

    # limit ciphers
    ssl_ciphers             HIGH:!ADH:!MD5;
    ssl_protocols           SSLv3 TLSv1;
    ssl_prefer_server_ciphers on;

    # proxy buffers
    proxy_buffers 16 64k;
    proxy_buffer_size 128k;

    ## default location ##
    location / {
        try_files $uri $uri/ /index.html?/$request_uri;


## http redirects to https ##
server {
    listen      80;
    server_name <your-server-name>;

    # Strict Transport Security
    add_header Strict-Transport-Security max-age=2592000;
    rewrite ^/.*$ https://$host$request_uri? permanent;


Upgrading an Ember CLI App

Steps to upgrade to the latest version of Ember CLI are included with each release, but these are the common steps one would follow to update Ember CLI using NPM from within your project directory.


  • Remove old global ember-cli
npm uninstall -g ember-cli
  • Clear NPM cache
npm cache clean
  • Clear Bower cache
bower cache clean
  • Install a new global ember-cli, replacing X.X.X with the version of ember-cli you want to install
npm install -g ember-cli@X.X.X

Project Update

  • Delete temporary development folders
rm -rf node_modules bower_components dist tmp
  • Update your project’s package.json file to use the latest version of ember-cli, replacing X.X.X with the version of ember-cli you want to install
npm install --save-dev ember-cli@X.X.X
  • Reinstall NPM dependencies
npm install
  • Reinstall Bower dependencies
bower install
  • Run the new project blueprint on your projects directory. Please follow the prompts, and review all changes (tip: you can see a diff by pressing d).
ember init

The most common sources of upgrade pain are not clearing out old packages in the first step of the project update and missing a change in the last step of the project update. Please review each change from the last step carefully to ensure you both have not missed a change from the upgrade and that you have not accidentally removed code you may have added to your project during your work.

When the upgrade process has completed, you should be able to issue the ember -v command and see that the version: noted in the resulting output matches the version you just upgraded to.

Common Issues

Content security policy

Ember CLI comes bundled with the ember-cli-content-security-policy addon which enables the Content Security Policy in modern browsers when running the development server.

The default header sent by the addon sends a policy where only content from 'self' is allowed. This means that by default, the browser will restrict your app from loading assets and data outside of localhost:4200 or doing any inline style or script modifications. If your app does any of these, you’ll see a lot of these errors:

Refused to execute inline script because it violates the following Content Security Policy directive: ...

You can get rid of these errors by modifing the CSP for your app. This is described in the addon readme.

Unsafe-Eval (CSP)

Some platforms that run on open web technology (ex. FirefoxOS) enforce strict CSP restrictions for apps. One of the more common restrictions is the Unsafe-Eval restriction, disallowing use of the eval() function or the eval operator. Since Ember CLI currently uses eval() for part of it’s integration with ES6 modules, this can be a problem.

To disable evals, add the wrapInEval: false flag to your Brocfile.js, for example:

1 // Brocfile.js
2 var EmberApp = require('ember-cli/lib/broccoli/ember-app');
3 ...
4 var app = new EmberApp({
5   wrapInEval: false
6 });
7 ...
8 module.exports = app.toTree();

npm package management with sudo

Installing packages such as bower with sudo powers can lead to permissions issues and ultimately to problems installing dependencies.

For example

Uncaught Error: Could not find module ember/resolver loader/loader.js:42

can be caused by installing bower with sudo. See https://gist.github.com/isaacs/579814 for a collection of various solutions.

Installing from behind a proxy

If you’re behind a proxy, you might not be able to install because ember-cli — or some of its dependencies — tries to git clone a git:// url. (In this scenario, only http:// urls will work).

You’ll probably get an error like this:

npm ERR! git clone git://github.com/jgable/esprima.git Cloning into bare repository '/home/<username>/.npm/_git-remotes/git-github-com-jgable-esprima-git-d221af32'...
npm ERR! git clone git://github.com/jgable/esprima.git
npm ERR! git clone git://github.com/jgable/esprima.git fatal: unable to connect to github.com:
npm ERR! git clone git://github.com/jgable/esprima.git github.com[0:]: errno=Connection timed out
npm ERR! Error: Command failed: fatal: unable to connect to github.com:
npm ERR! github.com[0:]: errno=Connection timed out

This is not a ember-cli issue per se, but here’s a workaround. You can configure git to make the translation:

git config --global url."https://".insteadOf git://

Usage with Sublime Text

If you are using Sublime Text 2 or 3 with ember-cli, by default it will try to index all files in your tmp directory for its GoToAnything functionality. This will cause your computer to come to a screeching halt @ 90%+ CPU usage, and can significantly increase build times. Simply remove these directories from the folders Sublime Text watches:

Sublime Text -> Preferences -> Settings - User

// folder_exclude_patterns and file_exclude_patterns control which files
// are listed in folders on the side bar. These can also be set on a per-
// project basis.
"folder_exclude_patterns": [".svn", ".git", ".hg", "CVS", "tmp/*"]

Using canary build instead of release

In bower.json instead of a version number use:

"ember": "components/ember#canary",

And, following dependencies add resolutions:

"resolutions": {
  "ember": "canary"

This can also be applied to Ember Data:

"ember-data": "components/ember-data#canary",

And, adding to resolutions:

"resolutions": {
  "ember-data": "canary"

Wipe your vendor directory clean then run bower install.

Removing default ember-cli libraries

  • To use ember-cli without Ember Data

npm rm ember-data --save-dev

  • To use ember-cli without ic-ajax

npm rm ember-cli-ic-ajax --save-dev

  • To reinstall latest Ember Data version

npm install ember-data --save-dev

Solving performance issues on windows

Build times on windows are longer than on linux or mac os. Much of that penalty is not because of node or ember-cli, but because of things monitoring your filesystem. If you can (selectively!) disable your virus scanner and the Search Index Host, you will see a substantial speedup. Here’s how:

Disable Windows Search Index for temporary files

  • Go to your control panel (Windows 8: Win+X, choose “control panel”)
  • Look for Indexing Options (Use the search bar)
  • Select the location that will most likely contain your project. Usually in User
  • Click Modify
  • This brings up a directory tree with checkboxes. Navigate to your project directory and uncheck the checkbox for /tmp or anywhere else you’d like.
  • Click OK

Partially Disable Search Index on Windows 8

Disable Windows Defender for temporary files

Windows defender will be active by default on any Windows 8 machine. On Windows 7 (or earlier) you might have Windows Security Essentials installed, which works pretty similar.

While you can exclude more than just the temporary files, this would also render a virus scanner pretty useless. Excluding temporary files won’t make you any less safe. Everything that ends up there would have been in /app or /vendor before.

  • Hit your Windows Key, then start typing “defen” which should bring up “Defender as first result”. Start it.
  • In Windows Defender, choose the Settings tab, then click on Excluded files and locations on the left.
  • Click Browse
  • Navigate to your project’s tmp directory.
  • Click OK
  • Click Add
  • Click Save changes

Exclude Temp Files from Windows Defender

Many Broccoli plugins and Ember CLI addons can use symlinks to speedup the build process. When working on the Windows platform there are some caveats involved in making sure Ember CLI and other plugins can use symlinks. If symlinks are not available plugins should fall back to copying files. However the speed benefits of symlinking are substantial, so it is worth the effort to make sure Ember CLI can take advantage of them.

In order to create symlinks the account running Ember CLI must have the SeCreateSymbolicLinkPrivilege. Users in the Administrators group have this permission already. However if UAC (User Access Control) is enabled users in the Administrators group must run their shell using Run As Administrator. This is because UAC strips away certain permissions from the Administrators group, including SeCreateSymbolicLinkPrivilege.

Run As Administrator

If the user account is not part of the Administrators group you will need to add the SeCreateSymbolicLinkPrivilege in order to allow the creation of symlinks. To do this open the Local Security Policy by typing Local Security Policy in the Run Box.

Under Local Policies -> User Rights Assignment find the Create symbolic links policy and double click it to add a new user or group. Once you add your user or group has been added your user should be able to create symlinks. Keep in mind if your user is part of the Administrators group and UAC is enabled you will still need to start your shell using Run as Administrator.

Enabling Symlinks

Usage with Vagrant

Vagrant is a system for automatically creating and setting up development environments that run in a virtual machine (VM).

Running your ember-cli development environment from inside of a Vagrant VM will require some additional configuration and will carry a few caveats.


In order to access your ember-cli application from your desktop’s web browser, you’ll have to open some forwarded ports into your VM. The default ports that ember-cli uses are 4200 and 35729 for its internal web server and livereload, respectively:

Vagrant.configure("2") do |config|
  # ... 
  config.vm.network "forwarded_port", guest: 4200, host: 4200
  config.vm.network "forwarded_port", guest: 35729, host: 35729

Watched Files

The way Vagrant syncs folders between your desktop and the VM will break the default mechanism ember-cli uses to watch files and cause issues when updates are subsequently compiled. To restore this functionality, you’ll have to make two changes:

  1. Fall back to polling when invoking the serve command: ember serve --watcher polling.

  2. Use nfs for synced folders.

VM Setup

When setting up your VM, install ember-cli dependencies as you normally would. If you’ve already run npm install in your project’s folder from your host machine, you’ll have to delete the node_modules folder and re-install those dependencies from the VM. This is particularly necessary if you have node dependencies that use native libraries (e.g., broccoli-sass, which uses the libsass C library).


The two most common Vagrant providers, VirtualBox and VMware Fusion, will both work. However, VMware Fusion is substantially faster and will use less battery life if you’re on a laptop. As of now, VirtualBox will use 100% of a single CPU core to poll for file system changes inside of the VM.




  • #2586 Set locationType to none in tests.
  • #2573 Added –silent option for quieter UI
  • #2458 Added additional file watching mechanism: Watchman This helps resolve the recent Node + Yosemite file watching issues, but also improves file watching (when available) for all *nix systems

    What is Watchman?

    Watchman runs as a standalone service, this allows it to manage file-watching for multiple consumers (in our case ember-cli apps)

    How do I used it? homebrew: brew install watchman other: https://facebook.github.io/watchman/docs/install.html windows: not supported yet, but it may happen

    What happens if its not installed?

    We fall back to the existing watcher NodeWatcher

    How do I force it to fallback to NodeWatch

    sh ember <command> --watcher=node

    Common problem: invalid watchman found, version: [2.9.8] did not satisfy [^3.0.0] this basically means you have an older version of watchman installed. Be sure to install 3.0.0 and run watchman shutdown-server before re-starting your ember server.

  • #2265 Added auto-restarting of server and triggering of LR on server/* file changes
  • #2535 Updated broccoli-asset-rev to 1.0.0
  • #2452 Including esnext via ember-cli-esnext per default
  • #2518 improved HTTP logging when using http-mocks and proxy by using morgan
  • #2532 Added support to run specific tests via ember test --module and ember test --filter
  • #2514 Added config.usePodsByDefault for users who wish to have blueprints run in pod mode all the time
  • Warn on invalid command options
  • Allow array of paths to the preprocessCss phase
  • Adding –pods support for adapters, serializers, and transforms
  • As part of the Ember 2.0 push remove controller types.
  • http-mock now follows ember-data conventions
  • many of ember-cli internals now are instrumented with [debug] usage: DEBUG=ember-cli:* ember <command> to see ember-cli specific verbose logging.
  • Added ember-cli-dependency-checker to app’s package.json
  • Added option to disable auto-start of ember app.
  • Added optional globbing to init with ember init <glob-pattern>, this allows you to re-blueprint a single file like: ember init app/index.html
  • Added support to test the app when built with --env production.
  • Update to Ember 1.8.1
  • Update to Ember Data v1.0.0-beta.11
  • #2351 Fix automatic generated model belongs-to and has-many relations to resolve test lookup.
  • #1888 Allow multiple SASS/LESS files to be built by populating outputPaths.app.css option
  • #2523 Added outputPaths.app.html option
  • #2472 Added Pod support for test blueprints.

Add much more: view entire diff


  • #2505 Added ability to dynamic add/remove module whitelist entries so that the ember-browserify addon can work
  • #2505 Added an addon postprocess hook for all javascript
  • #2271 Added Addon.prototype.isEnabled for an addon to exclude itself from the project at runtime.
  • #2451 Ensure that in-repo addons are watched.
  • #2411 Add preBuild hook for addons.



  • [BREAKING ENHANCEMENT] Remove hard-coded support for broccoli-less-single, use ember-cli-less for .less support now. #2210
  • [ENHANCEMENT] Provide a helpful error if the configuration info cannot be read from the proper <meta> tag. #2219
  • [ENHANCEMENT] Allow test filtering from the command line. Running ember test --filter "foo bar" or ember test --server --filter "foo bar" will limit test runs to tests that contain “foo bar” in their module name or test name. #2223
  • [ENHANCEMENT] Add a few more content-for hooks to index.html and tests/index.html. #2236
  • [ENHANCEMENT] Properly display the file causing build errors in ember build --watch and ember serve commands. #2237, #2246, and #2297
  • [ENHANCEMENT] Update broccoli-asset-rev to 0.3.1. #2250
  • [ENHANCEMENT] Add ember-export-application-global to allow easier debugging. #2270
  • [BUGFIX] Fix default .gitignore to properly match bower_components. #2285
  • [ENHANCEMENT] Display baseURL in ember serve startup messages. #2291
  • [BUGFIX] Fix issues resulting in files outside of tmp/ being removed due to following of symlinks. #2290 and #2301
  • [ENHANCEMENT] Add –watcher=polling option to ember test --server. This provides a work around for folks having EMFILE errors in some scenarios. #2296
  • [ENHANCEMENT] Allow opting out of storing the applications configuration in the generated index.html via storeConfigInMeta option in the Brocfile.js. #2298
  • [BUGFIX] Update ember-cli-content-security-policy and ember-cli-inject-live-reload packages to latest version. Allows livereload to function properly regardless of host (0.1.0 always assumed localhost for the livereload server). #2306
  • [ENHANCEMENT] Update internal dependencies to latest versions. #2307
  • [BUGFIX] Allow overriding of vendor files to not loose required ordering. #2312
  • [ENHANCEMENT] Add bowerDirectory to Project model (discovered on initialization). #2287


  • [ENHANCEMENT] Allow addons to inject middleware into testem. #2128
  • [ENHANCEMENT] Add to app/index.html and tests/index.html. #2236
  • [ENHANCEMENT] Add to tests/index.html. #2236
  • [ENHANCEMENT] Add to tests/index.html. #2236
  • [ENHANCEMENT] Allow adding multiple bower packages at once via Blueprint.prototype.addBowerPackagesToProject. #2222
  • [ENHANCEMENT] Allow adding multiple NPM packages at once via Blueprint.prototype.addPackagesToProject. #2245
  • [ENHANCEMENT] Ensure generated addons are in strict mode. #2295
  • [BUGFIX] Ensure that addon’s with addon/styles/app.css are able to compile properly (copying contents of addon/styles/app.css into vendor.css). #2301
  • [ENHANCEMENT] Provide the httpServer instance to serverMiddleware (and ./server/index.js). #2302


  • [ENHANCEMENT] Tweak helper blueprint to make it easier to test. #2257
  • [ENHANCEMENT] Streamline initializer and service blueprints. #2260


  • [BUGFIX] Fix symlink regression in Windows (update broccoli-file-remover to 0.3.1). #2204


  • [ENHANCEMENT] Add symlinking to speed up Broccoli builds. #2125
  • [BUGFIX] Fix issue with livereload in 0.0.47. #2176
  • [BUGFIX] Change content security policy addon to use report only mode by default. #2190
  • [ENHANCEMENT] Allow addons to customize their ES6 module prefix (for addon tree). #2189
  • [BUGFIX] Ensure all addon hooks are executed in addon test harness. #2195



  • [ENHANCEMENT] Add --pod option to blueprints for generate and destroy. Add fileMapTokens hook to blueprints, and optional blueprint file tokens __path__ and __test__ for pod support. #1994
  • [ENHANCEMENT] Provide better error messages when uncaught errors occur during ember build and ember serve. #2043
  • [ENHANCEMENT] Do not use inline <script> tags. Set the stage for enabling content security policy. #2058
  • [ENHANCEMENT] Add ember-cli-content-security-policy addon when running development server (see content-security-policy.com for details). #2065
  • [BREAKING] Remove environment and getJSON options to EmberApp (in the Brocfile.js).
  • [ENHANCEMENT] Add configPath option to EmberApp (in the Brocfile.js) to allow using a custom file for obtaining configuration information. #2068
  • [BUGFIX] Use url.parse instead of manually checking baseURL. This allows app://localhost/ URLs needed for node-webkit. #2088
  • [BUGFIX] Remove duplicate warning when generating controllers. #2066
  • [BREAKING ENHANCEMENT] Move config information out of the assets/my-app-name.js file and into a <meta> tag in the document head. #2086
    • Removes <my-app-name>/config/environments/* from module system output.
    • Makes build output the same regardless of environment config.
    • Makes injection of custom config information as simple as adding/modifying/customizing the meta contents.
  • [BREAKING BUGFIX] Update loader.js entry in bower.json to use the proper name.

    This requires editing bower.json to change:

"loader": "stefanpenner/loader.js#1.0.1",


"loader.js": "stefanpenner/loader.js#1.0.1", * [BREAKING ENHANCEMENT] Replace in `index.html` with. #2153


  • [BUGFIX] addon/ directory is no longer required when running local development server inside an addon. #2044
  • [BUGFIX] Use the specified name for the addon (was previously using dummy for all addon’s names). #2042
  • [ENHANCEMENT] Add Registry.prototype.remove to make it easier to remove preprocessor plugins. #2048
  • [ENHANCEMENT] Add Registry.prototype.extensionsForType to make it easier to detect what extensions are support for a given type of file (js, css, or template files). #2050
  • [BUGFIX] Allow addon tree to contain any filetype that is known by the JS preprocessor registry. #2054
  • [BUGFIX] Ensure that addons cannot override the application configuration (in the config hook). #2133
  • [ENHANCEMENT] Allow addons to implement contentFor method to add string output into the associated `` section in index.html. #2153


  • [ENHANCEMENT] Add description for blueprints created by ember generate blueprint. #2062
  • [ENHANCEMENT] Add in-repo-addon generator. #2072
  • [ENHANCEMENT] Add before and after options to Blueprint.prototype.insertIntoFile. #2122
  • [ENHANCEMENT] Allow git based application blueprints. #2103



  • [BREAKING ENHANCEMENT] Moved modulePrefix to config/environment.js. #1933
  • [BREAKING ENHANCEMENT] Remove window.MyAppNameENV. You will now need to import the configuration instead of relying on using the global. #1903.

javascript import ENV from '<appName>/config/environment'; ENV.API_HOST; // example.com

  • [ENHANCEMENT] Allowing config of asset output paths. #1904
  • [ENHANCEMENT] Add a default .ember-cli file and document disableAnalytics. #1801
  • [BUGFIX] Add location type for test environment. This generally makes using ember test with a custom baseURL work properly. #1915
  • [ENHANCEMENT] Allow multiple pre-processors per type (for example, using broccoli-sass AND broccoli-less is now possible). #1918
  • [ENHANCEMENT] Update startApp to provide app configuration. #1329
  • [BUGFIX] Remove manual env === 'production' checks. #1929
  • [BUGFIX] Fixed an issue where project.config() could be called with undefined environment when starting express server. #1959
  • [ENHANCEMENT] Improve blueprint self-documentation by adding additional details to ember help generate. #1279
  • [ENHANCEMENT] Update broccoli-asset-revto 0.1.1. #1945
  • [ENHANCEMENT] Update app blueprint’s package.json/bower.json to depend on ember-data. #1873
  • [BUGFIX] Ensure that things loaded by server/index.js override addons. This changes the middleware ordering so that the app’s middlewares are loaded before the internal middlewares. #2008
    • [BUGFIX] Removed broccoli-sweetjs from the internal preprocessor registry. #2014
    • [ENHANCEMENT] Pull podModulePrefix from config/environment.js. #2024
    • [BUGFIX] Exit with a non-zero exit code (to indicate failure), and provide a nice error message if ember test runs nothing. #2025


    • [ENHANCEMENT] Allow addons to return a public tree. By default anything in an addon’s public/ folder will be copied into a folder for that addon’s name in the output path. #1930
    • [BUGFIX] Remove extra nesting of addon/styles tree. Previously, the addon styles tree was looking for addon/styles/styles/. #1964
    • [ENHANCEMENT] Add config hook for addons. #1972
    • [BUGFIX] Ensure we do not add ember-addon twice when running ember init (to upgrade an addon). #1982
    • [BUGFIX] Allow addon/templates to be properly available inside the my-addon-name.js file with the correct module name. #1983


    • [ENHANCEMENT] Add empty function to resource blueprint when resource is singular. #1946
    • [BUGFIX] Do not inject application route into app/router.js. #1953
    • [ENHANCEMENT] Add Blueprint.prototype.lookupBlueprint which allows a blueprint to lookup other Blueprints. This makes it much easier to provide Blueprints that augment existing internal blueprints without having to copy and override them completely. #2016



  • [BUGFIX] Provide useful error message when app/styles/app.ext is not found. #1866 and #1894
  • [ENHANCEMENT] Updated dependency broccoli-es3-safe-recast. #1891 and #1898
  • [ENHANCEMENT] Updated dependency broccoli-merge-trees. #1891 and #1898
  • [ENHANCEMENT] Updated dependency fs-extra. #1891 and #1898
  • [ENHANCEMENT] Updated dependency proxy-middleware. #1891 and #1898
  • [ENHANCEMENT] Updated dependency tiny-lr. #1891 and #1898
  • [BUGFIX] Update broccoli-caching-writer to fix performance regression. #1901
  • [BUGFIX] Ensure that a .bowerrc without directory specified does not error. #1902


  • [BUGFIX] Allow addons with styles to function properly. #1892


  • [BUGFIX] Fix ember g http-mock foo output to pass JSHint. #1896



  • [BUGFIX] Fix ember init command in empty directory. #1779
  • [ENHANCEMENT] Add triggerEvent to tests/.jshintrc. #1782
  • [ENHANCEMENT] Allow opting out of analytics via .ember-cli config file. #1797
  • Bump ember-cli-qunit version.
  • [BUGFIX] Update broccoli-caching-writer dependents to allow linking fallback (enables easier usage of ember-cli from within Vagrant). #1799
  • [BUGFIX] Avoid issue where ember init stalls on fresh system due to bower install prompting for permission to use analytics. #1805
  • [BUGFIX] Allow usage of standard Node.js functionality in config/environments.js (fixes a regression in 0.0.42). #1809
  • [ENHANCEMENT] Make current environment available modules. #1820
  • [BUGFIX] Ensures that AppNameENV and EmberENV are setup before the vendor files have been loaded (changes in 0.0.42 caused enabling Ember feature flags impossible from config/environments.js). #1825
  • [ENHANCEMENT] Ensures that the <base> tag changes when the config file is updated. #1825
  • [ENHANCEMENT] Injects the /tests/index.html with the test environment configuration (was previously whatever server was running). #1825
  • [ENHANCEMENT] bower_components and vendor are kept separate for import purposes. When we moved to separate directories for bower_components/ and vendor/ in 0.0.41, to allow for users to upgrade easier we merged those two folders into one single vendor tree. This meant that you would still app.import('vendor/baz/foo.js') and import Foo from 'vendor'; even if the file actually resides in bower_components/. This lead to much confusion and forced users to understand the internals that are going on (merging the two directories into vendor/). Now you would import things from bower_components/ or vendor/ if that is where they were on disk. #1836
  • [BUGFIX] Allow nested output path, if path does not previously exist. #1872
  • [ENHANCEMENT] Update ember-cli-qunit to 0.1.0. To avoid vendoring files in the addon and prevent having to run bower install within the addon itself (in a postinstall hook) the addon now installs its required packages directly into the applications bower.json file. This speeds up the build and make addon development much easier. #1877


  • [BUGFIX] ember g http-proxy does not truncate the base path on proxied requests. #1874
  • [ENHANCEMENT] Add empty function to ember g resource generator. #1817
  • [ENHANCEMENT] Add by default when generating a route template. #1819
  • [ENHANCEMENT] Remove use of deprecated view.state property. #1826
  • [BUGFIX] Allow blueprints without files. #1829
  • [ENHANCEMENT] Make ember g adapter extend from application adapter if present. #1831
  • [ENHANCEMENT] Add –base-class options to ember g adapter. #1831
  • [BUGFIX] Quote module name in object literal for ember g http-mock. #1823
  • [ENHANCEMENT] Add Blueprint.prototype.addBowerPackageToProject. #1830
  • [ENHANCEMENT] Add Blueprint.prototype.insertIntoFile. #1857


  • [ENHANCEMENT] Expose Addon.prototype.isDevelopingAddon function. #1785
  • [ENHANCEMENT] Expose Addon.prototype.treeGenerator function, that automatically handles the returning an unwatchedTree vs the bare directory (therefore causing it to be watched). #1785
  • [ENHANCEMENT] Add default Addon.prototype.blueprintsPath implementation. Now if an addon has a blueprints/ folder, it will be automatically used as the blueprintsPath. #1876


  • [ENHANCEMENT] Throw an error if an Addon does not specify a name. #1741
  • [ENHANCEMENT] Extract CoreObject into a standalone package (core-object). #1752
  • [ENHANCEMENT] Set a default baseURL in test to allow testem to function properly with a custom baseURL specified. #1748
  • [BUGFIX] Update broccoli-concat to solve a performance issue with the recent addon changes (allows better caching when no changes are detected). #1757 and #1766
  • [BUGFIX] Bring .bowerrc file back for app blueprint. Helps alleviate upgrade issues, and ensures a parent directories .bowerrc cannot break an ember-cli app. #1761
  • [ENHANCEMENT] Update and clarify the default project README. #1768
  • [BUGFIX] Ensure that app.import‘ed assets can be properly watched (and trigger a reload upon change). #1774
  • [BUGFIX] Ensure that postBuild hook is called on addons during ember build. #1775
  • [BREAKING ENHANCEMENT] Enabled automatic reloads on config/environment.js changes. #1777
  • [BREAKING ENHANCEMENT] Export the current configuration to a module (`my-app-name/config/environment’). #1777


  • [ENHANCEMENT] Allow calling this._super.someMethodName() in subclasses of CoreObject. #1721
  • [ENHANCEMENT] .jshintrc: disable esnext Promise global (prevents issues when RSVP Promise was intended but (non-universally-implemented) global Promise was used instead. #1723
  • [BUGFIX] Prevent deletion of files when invalid output-path is provided. #1649
  • [BUGFIX] Fix the /tests URL in IE8. #1707
  • [ENHANCEMENT] Remove .bowerrc file from application blueprint (will still use directory specified in .bowerrc, but uses the default of bower_components/ if no .bowerrc exists). #1679
  • [BUGFIX] Fixes support for .ember-cli settings file. #1676
  • [BUGFIX] Blueprint: replace multiple occurences of __name__ with module name. #1658
  • [ENHANCEMENT] Replace internal live-reload middleware with addon. #1643
  • [ENHANCEMENT] Add .travis.yml to app blueprint. #1636
  • [ENHANCEMENT] Allow individual Blueprints to determine if an entity name is required. #1631
  • [ENHANCEMENT] Move qunit support into an addon. #1295
  • [BUGFIX] Running ember new foo-bar --dry-run does not create new directory. #1602
  • [ENHANCEMENT] Allow addons to return an addon tree that will be namespaced with the addons name. #1544
  • [BUGFIX] Ensure non assets/ files can be served from public/ or when added via app.import (using the destDir). #1549
  • [ENHANCEMENT] Update ember-resolver version (allows for components and their templates to be grouped together). #1540
  • [ENHANCEMENT] Update testem version. #1539
  • [ENHANCEMENT] Remove originate from application blueprint.
  • [ENHANCEMENT] Add EditorConfig file to blueprints. #1507
  • [ENHANCEMENT] Add `Blueprint#beforeInstall”. #1498
  • [ENHANCEMENT] Add --type option (and check) to controller and route generators. #1498
  • [BUGFIX] Call normalizeEntityName hook before locals hook #1717
  • [ENHANCEMENT] replace multiple instances of name in blueprints.
  • [ENHANCEMENT] adds http-proxy for explicit, multi proxy use#1474
  • [BREAKING ENHANCEMENT] renames apiStub to http-mock to match other http-related generators [#1474] (https://github.com/stefanpenner/ember-cli/pull/1530)
  • [ENHANCEMENT] Log proxy server traffic when using ember serve --proxy #1583
  • [ENHANCEMENT] Remove chain from express server #1474
  • [ENHANCEMENT] Remove Blueprint lookup failure stacktrace #1476
  • [ENHANCEMENT] –verbose errors option to have SilentError output stacktrace #1480
  • [BUGFIX] Modify service blueprint to create explicit injection #1493
  • [ENHANCEMENT] Generating a helper now also generates a test #1503
  • [BUGFIX] Do not run JSHint against trees returned from an addon.
  • [BREAKING ENHANCEMENT] Addons can pull in test assets into test tree #1453
  • [BREAKING ENHANCEMENT] Addon model’s _root renamed to root #1537
  • [ENHANCEMENT] Addons can recursively add other addons #1509
  • [ENHANCEMENT] Upgrade loader.js to 1.0.1. #1543
  • [BUGFIX] Allow public/ to contain files in the root of the project. #1549
  • [ENHANCEMENT] Add robots.txt and crossdomain.xml files in the root of the project. #1550
  • [BUGFIX] Generating mixins and utils with several levels of nesting no longer produces a failing test. #1551
  • [BREAKING ENHANCEMENT] bower assets moved to bower_components instead of vendor #1436
  • [ENHANCEMENT] Move history support into a separate internal addon. #1552
  • [ENHANCEMENT] don’t assume value of bowerrc.directory #1553
  • [ENHANCEMENT] es6 namespaced addons #1544
  • [ENHANCEMENT] Removed use of memoize from EmberApp. Allows multiple EmberApps to be instantiated #1361
  • [ENHANCEMENT] Add ember destroy command (removes files added by generate command). #1547
  • [BUGFIX] Ensure router.js is not modified when ember g route foo –dry-run #1570
  • [ENHANCEMENT] Add possibility to hide #ember-testing-container while testing #1579
  • [BUGFIX] Fix EmberAddon vendor tree #1606
  • [ENHANCEMENT] Addon blueprint #1374
  • [BUGFIX] Fix addons with empty directories #
  • [BUGFIX] Fix tests/helpers/start-app.js location from addon generator #1626
  • [BUGFIX] Allow addons to use history support middleware #1632
  • [ENHANCEMENT] Upgrade broccoli-ember-hbs-template-compiler to 1.6.1.
  • [ENHANCEMENT] Allow file patterns to be ignored by LiveReload #1706
  • [BUGFIX] Switch to OS-friendly line endings #1718
  • [BUGFIX] Prevent file deletions when the build --output-path is a parent directory #1730


  • [BUGFIX] fix detection of static files to allow periods in urls #1399
  • [BUGFIX] fix processing of import statements in css #1400
  • [BUGFIX] fix detection of requests to be proxied #1263
  • [BUGFIX] fix ember update (broken promises) #1265
  • [BUGFIX] eagerly requireing inquirer was cost ~100ms -> 150ms on boot [https://github.com/stefanpenner/ember-cli/commit/0ae78df5b4772b126facfed1d3203e9c695e80a1)
  • [BUGFIX] Fix issue with invalid warnings (regarding files in the root of vendor/) on Windows. #1264
  • [BUGFIX] Fix addons being unable to use app.import to pull in non-js/css assets from their own vendor/ tree. #1159
  • [ENHANCEMENT] When using app.import to import non-js/css assets, you can now specify the destination of the asset. #1159
  • [BUGFIX] Fix issue with ember build failing if the public/ folder was deleted. #1270
  • [BREAKING ENHANCEMENT] CoffeeScript support is now brought in by ember-cli-coffeescript. To use CoffeeScript with future versions run npm install --save-dev ember-cli-coffeescript (and broccoli-coffee is no longer needed as a direct dependency). #1289
  • [BUGFIX] Blueprint.prototype.normalizeEntityName’s return value should update the entity name. #1283
  • [BREAKING ENHANCEMENT] Move test only js/css assets into test-vendor.js and test-vendor.css respectively. #1288
  • [ENHANCEMENT] Update default Ember version to 1.6.0.
  • [ENHANCEMENT] Display friendly error message when the server fails to start (e.g. address in use). #1306
  • [BREAKING ENHANCEMENT] Rename test-vendor.{css,js} to test-support.{css,js} to better reflect its role. #1320
  • [BUGFIX] Store version check information correctly, and only change the lastVersionCheckAt timestamp when the version is checked from npm. #1323
  • [BUGFIX] Update broccoli-es3-safe-recast to fix bugs with incorrectly replaced segments. #1340
  • [ENHANCEMENT] EmberApp can take jshintrc path options for app and test jshintrc files. #1341
  • [ENHANCEMENT] Using broccoli-sass > 0.2.0 now allows you to use .sass files. #1367
  • [ENHANCEMENT] EmberAddon constructor to build an EmberApp object with defaults for addon projects. #1343
  • [ENHANCEMENT] Allow addons to be vendored outside of node modules #1370
  • [ENHANCEMENT] Make “ember version” show NPM and Node version (versions of all loaded modules with “–verbose” switch). #1307
  • [BUGFIX] Duplicate-checking for generating routes now accounts for "-syntax. #1371
  • [BREAKING BUGFIX] Standard variables passed in to Blueprints now handle slashes better. Breaking if you relied on the old behavior. #1278
  • [BUGFIX] Generating a route named ‘basic’ no longer adds it to router.js. #1390
  • [ENHANCEMENT] EmberAddon constructor defaults process.env.EMBER_ADDON_ENV to “development”. #
  • [ENHANCEMENT] Tests now run with the “test” environment by default, config/environment.js contains an (empty) section for the “test” environment #1401
  • [ENHANCEMENT] Add Git initialization to ember new command #1369
  • [ENHANCEMENT] Addons can export an object instead of a function #1377
  • [ENHANCEMENT] Addons will automatically load a generic addon constructor that includes app/vendor trees based on treesFor property if no main key is specified in package.json. #1377
  • [ENHANCEMENT] Disable LOG_RESOLVER flag to reduce console.log noise by default. #1431
  • [ENHANCEMENT] Update broccoli-asset-revto 0.0.17
  • [ENHANCEMENT] Upgrade ember-qunit to 0.1.8. #1427
  • [BUGFIX] Fix pod based templates (was broken with the advent of the templates tree). #4138
  • [ENHANCEMENT] ExpressServer middleware extracted to addons that are always pulled into every Project first #1446


  • [BUGFIX] ember build --watch should run until SIGTERM. #1197
  • [BUGFIX] Failed build should return non-zero exit code. #1169
  • [BUGFIX] improve startup time by up to 3x
  • [BUGFIX] Ensure ember generate always operate in relation to project root. #1165
  • [ENHANCEMENT] Upgrade ember-cli-ember-data to 0.1.0. #1178
  • [BUGFIX] Update ember-cli-ic-ajax to prevent warnings. #1180
  • [BUGFIX] Throw error when trailing slash present in argument to ember generate. #1184
  • [ENHANCEMENT] Don’t expect Ember or Em to be global in tests. Ember or Em needs to be imported. #1201
  • [BUGFIX] Make behaviour of --dry-run more obvious & add --skip-npm and --skip-bower. #1205
  • [ENHANCEMENT] Remove .gitkeep files from ember init inside an existing project #1209
  • [ENHANCEMENT] Addons can add commands to the local ember command. #1196
  • [ENHANCEMENT] Addons can implement a postBuild hook. #1215
  • [ENHANCEMENT] Addons can add post-processing steps to the Brocfile.js process. #1214
  • [ENHANCEMENT] broccoli-asset-rev has been moved to an addon using the standard addon post-processing hooks. #1214
  • [ENHANCEMENT] Allow app.toTree to accept an array of additional trees to merge in the final output. #1214
  • [BUGFIX] Only run JSHint after preprocessing. #1221
  • [ENHANCEMENT] Addons can add blueprints. #1222
  • [ENHANCEMENT] Allow testing of production assets. #1230
  • [ENHANCEMENT] Provide Ember CLI version to Project model. #1239
  • [BREAKING ENHANCEMENT] Split app/templates into its own tree to prevent preprocessing template files as if they were JavaScript. #1238
  • [ENHANCEMENT] Print a warning when using app.import for assets in the root of vendor/ (this is a significant performance penalty).
  • [ENHANCEMENT] Model generation no longer requires an attribute type. #1252
  • [ENHANCEMENT] Allow vendor files to be configurable. #1187


  • accidentally deploy with node v0.0.11 which builds an invalid package


  • [BUGFIX] ensure the CLI exits with the correct status, fixes hanging tests and some non-graceful exit cleanups #1150
  • [BUGFIX] Ensure EDITOR is set before allowing edit in ember init. #1090
  • [BUGFIX] Display message to user when diff cannot be applied cleanly #1091
  • [ENHANCEMENT] Notify when an ember-cli update is available, and add ember update command. #899
  • [BUGFIX] Ensure that build output directory is cleaned up properly. #1122
  • [BUGFIX] Ensure that non-zero exit code is used when running ember test with failing tests. #1123
  • [BREAKING ENHANCEMENT] Change the expected interface for the ./server/index.js file. It now receives the instantiated express server. #1097
  • [ENHANCEMENT] Allow addons to provide server side middlewares. #1097
  • [ENHANCEMENT] Automatically pluralize the attribute when generating a model. #1120
  • [BUGFIX] Make sure non-dasherized model attributes are also added to generated tests. #1120
  • [ENHANCEMENT] Upgrade ember-qunit-notifications to 0.0.3. #1117
  • [ENHANCEMENT] Allow addons to specify load ordering. #1132
  • [ENHANCEMENT] Adds ember build --watch #1131
  • [BREAKING ENHANCEMENT] Accept options as second parameter of ember-app#import. Pass modules as exports. #1121


  • deployed bundled package with outdated bundled depds… Likely user error (by @stefanpenner)


  • [BUGFIX] Ensure that vendored JS files are concatted in a safe way (to prevent issues with ASI). #988
  • [ENHANCEMENT] Use the Project model to load the project name and environment configuration (removes boilerplate from Brocfile.js). #989
  • [BUGFIX] Pass --port option through when calling ember test --port 8987 (allows overriding the port when running concurrent ember test commands). #991
  • [ENHANCEMENT] Add .ember-cli configuration file. #563
  • [ENHANCEMENT] Add edit capability to ember init. #1000
  • [ENHANCEMENT] Add the current environment to the application config (the MyApplicationENV global). #1017
  • [BUGFIX] Ensure that the project .jshintrc file is looked up in the project’s root. #1019
  • [ENHANCEMENT] Allow addons to hook into the application build process. #1025
  • [ENHANCEMENT] Allow addons to register custom preprocessors. #1030
  • [BUGFIX] Prevent route blueprint adding duplicate entries to router.js #1042
  • [ENHANCEMENT] Add blueprint listing in ember help generate. #952
  • [BUGFIX] Add missing descriptions for build, serve, and test commands. #1045
  • [ENHANCEMENT] Do not remove output directory. This allows easier cross-project symlinking (previous behavior broke the link when the output path was destroyed). #1034
  • [ENHANCEMENT] Keep output path (/dist by default) up to date with both ember server and ember build. #1034
  • [ENHANCEMENT] Use the ember-cli-ic-ajax addon to bring in ic-ajax. #1047
  • [ENHANCEMENT] Use the ember-cli-ember-data addon to bring in ember-data. #1047
  • [BUGFIX] Allow fingerprinting to be enabled/disabled in a more custom way. #1066
  • [ENHANCEMENT] Use ember-addon as the “addon” keyword. #1071
  • [ENHANCEMENT] loader should now support CJS mode of AMD.
  • [ENHANCEMENT] Upgrade broccoli-asset-rev to 0.0.6 and allow passing a customHash in fingerprint options. #1024


  • [BUGFIX] broccoli-es6-safe-recast now once again has one-at-a-time semantics for incremental rebuilds
  • [BUGFIX] upgrade broccoli-sane-watcher to include better error messages when attempting to watch non-existent files
  • [ENHANCEMENT] Allow opting out of ES3SafeFilter. #966
  • [ENHANCEMENT] Provide --watcher option for switching between polling and events-based file watching. #970
  • [BUGFIX] Ensure that tmp/ is cleaned up after running ember server or ember test --server. #971
  • [BUGFIX] Fix errors with certain generate commands that depend on inflection. f016820
  • [BUGFIX] Do not wrap vendor assets in eval when wrapInEval is set. #983
  • [ENHANCEMENT] Use wrapInEval by default for application assets when running in development. #983


  • [BUGFIX] broccoli-sane-watcher now recovers after filters throw #940
  • [ENHANCEMENT] Use ember-data.prod.js when ENV=production #909.
  • [BUGFIX] Ensure that config/environment is findable and required when setting up baseURL for server. #916
  • [BUGFIX] Fix importing of non-JS/CSS #915
  • [ENHANCEMENT] Use window.MyProjectNameENV instead of window.ENV. #922
  • [BUGFIX] Disallow projects with periods in their name. #927
  • [ENHANCEMENT] Allow customization of Javascript minification options. #928
  • [BUGFIX] TestServer now waits until the build is done before starting. #932
  • [ENHANCEMENT] Upgrade leek to 0.0.6. #934
  • [BUGFIX] leek upgrade fixes #642, #709
  • [ENHANCEMENT] Allow disabling of automatic fingerprinting. #930
  • [ENHANCEMENT] Update ember-cli-shims to add ember-data shim. #941
  • [ENHANCEMENT] Update default jshint settings to require importing Ember. #941
  • [ENHANCEMENT] Bring generators in-house via blueprints. #747
  • [BUGFIX] Only process applicaiton code with ES3SafeFilter. #949
  • [ENHANCEMENT] Separate applicaiton code from vendor code. Generate /assets/vendor.js for vendored code. #949
  • [ENHANCEMENT] Provide registry access from EmberApp. #955
  • [BUGFIX] Ensure that EmberENV is setup (to allow enabling flagged features). #957


  • [ENHANCEMENT] less CPU intensive watching thanks to @krisselden’s https://github.com/krisselden/broccoli-sane-watcher and @amasad’s https://github.com/amasad/sane
  • [BUGFIX] Upgrade broccoli-es6-concatenator to 0.1.6 to fix a concatenation issue. broccoli-es6-concatenator#17
  • [BUGFIX] prevent pointless event emitter memory leak warning #850
  • [ENHANCEMENT] add and es3 safe transpile step: specifically promise.catch and promise.finally -> promise[‘catch’] & promise[‘finally’]. In addition we cover afew more variables see: https://github.com/stefanpenner/es3-safe-recast #823
  • [ENHANCEMENT] Load the vendor.css in the rendered HTML. #728
  • [ENHANCEMENT] Allow testem port to be specified when running ember test --server. #729
  • [BUGFIX] Use EMBER_ENV if specified in ENV_VARIABLES EMBER_ENV=production ember build. #753
  • [ENHANCEMENT] If both EMBER_ENV and –environment are specified, use EMBER_ENV. #753
  • [ENHANCEMENT] Update broccoli-jshint to 0.5.0 (more efficient caching for faster rebuilds). #758
  • [ENHANCEMENT] Ensure that the app/templates/components directory is created automatically. #761
  • [BUGFIX] For ember-init, Use app name if specified, over package.json or cwd name. #792
  • [ENHANCEMENT] Add support for Web Notifications for QUnit test suite with ember-qunit-notifications. #804
  • [BUGFIX] Ensure that files in app/ are JSHinted properly. #832
  • [ENHANCEMENT] Update ember-load-initializers to 0.0.2.
  • [ENHANCEMENT] Add broccoli-asset-rev for fingerprinting + source re-writing. #814
  • [BUGFIX] Prevent broccoli from watching node_modules/ember-cli/lib/broccoli/. #857
  • [BUGFIX] Prevent collision between running ember server and ember test --server simultaneously. #862
  • [ENHANCEMENT] Show timing and slow tree listing for each rebuild. #860 & #865
  • [BUGFIX] Disable wrapInEval by default. #866
  • [ENHANCEMENT] Allow passing tests and hinting to new EmberApp(). #876
  • [BUGFIX] Prevent slow tree printout during ember test --server from bleeding through testem UI.#877
  • [ENHANCEMENT] Remove unused vendor/_loader.js file. #880
  • [ENHANCEMENT] Allow disabling JSHint tests from within QUnit UI. #878
  • [ENHANCEMENT] Upgrage ember-resolver to 0.1.1 (and lock down version in bower.json). #885


  • [FEATURE] The baseURL in your environment.js now gets the leading and trailing slash automatically if you omit them. #683
  • [FEATURE] The development server now serves the site under the specified baseURL. #683
  • [FEATURE] Expose server: Bring back the API stub’s functionality, give users the opportunity to add their own middleware. #683
  • [ENHANCEMENT] project.require() can now be used to require files from the user’s project. #683
  • [ENHANCEMENT] Plugins can fall back to alternate file extensions (i.e scss, sass)
  • [BUGFIX] Fix incorrect generation of all vendor/ assets in build output. #645
  • [ENHANCEMENT] Update to Broccoli 0.12. Prevents double initial rebuilds when running ember server. #648
  • [BREAKING ENHANCEMENT] The generated app.js and app.css files are now named for your application name. #638
  • [ENHANCEMENT] added first iteration of a slow but thorough acceptance test. A new app is generated, depedencies resolve, and the test for that base app are run. #614
  • [ENHANCEMENT] Use handlebars-runtime in production. #675
  • [BUGFIX] Do not watch vendor/ for changes (watching vendor drammatically increases CPU usage). #693
  • [ENHANCEMENT] Minify CSS #688
  • [ENHANCEMENT] Allows using app.import for things other than JS and CSS (i.e. fonts, images, json, etc). #699
  • [BUGFIX] Fix ember --help output for test and version commands. #701
  • [BUGFIX] Fix package.json preprocessor dependencies not being included in the registry. #703
  • [BUGFIX] Update testem version to fix error thrown for certain assertions when running ember test, also fixes issue with ember test --server in Node 0.10. #714


  • [BUGFIX] ` ENV.LOG_MODULE_RESOLVER` must be set pre-1.6 to get better container logging.
  • [FEATURE] Added support for ember-scripts preprocessing.
  • [ENHANCEMENT] Refactor blueprint.js to remove unnecessary variable assignment, change double iteration to simple reduce, and remove function that only swapped arguments and called through. #537
  • [ENHANCEMENT] Refactor test-loader.js for readability and to prevent unnecessary iterations #524
  • [ENHANCEMENT] Remove Ember.setupForTesting and Router.reopen({location: 'none'}); from test helpers #516.
  • [ENHANCEMENT] Update loom-generators-ember-appkit to ^1.1.1.
  • [BUGFIX] Whitelist ic-ajax exports to prevent import validation warnings. #533
  • [BUGFIX] ember init fails on NULL_PROJECT (#546)
  • [ENHANCEMENT] Files added by ember-cli should not needed to be specified in Brocfile.js. #534
  • [ENHANCEMENT] Ensure minified output is using compress and mangle options with uglify-js. #564
  • [BUGFIX] Update to Broccoli 0.10.0. This should resolve the primary issue ember-cli has on Windows. #578
  • [ENHANCEMENT] Always Precompile Handlebars templates. #574
  • [ENHANCEMENT] Update to Broccoli 0.11.0. This provides better timing information for Watcher. #587
  • [ENHANCEMENT] Track rebuild timing. #588
  • [ENHANCEMENT] Remove global defined helpers in favor of http://api.qunitjs.com/equal http://api.qunitjs.com/strictEqual/, etc. #579
  • [BREAKING BUGFIX] No longer rely on broccoli-bower to automatically import vendored files. Use app.import to import dependencies and specify modules to whitelist. #562
  • [ENHANCEMENT] Removed proxy-url and proxy-host parameters and introduced proxy param with full proxy url. (#567)
  • [ENHANCEMENT] Update to jQuery 1.11.1.
  • [ENHANCEMENT] When using non-NPM installed package (aka “running on master”) the branch name and SHA are now printed along with the prior version number. #634


  • [BUGFIX] The blueprinted application’s package.json forces an older version of ember-cli. Fixed in #518.


  • Changes to index.html: Script tags were moved into body, ENV and the app are now defined in the same script tag.
  • patch to quickfix some broccoli + Windows IO issues. We expect a proper solution soon, but this will hold us over (#493).
  • Add a custom watcher to make broccoli more usable on windows by catching file errors (493).
  • Add ember test with Testem integration (388).
  • some improvements to bower dependency management, unfortunately until bower.json stabilizes broccoli-bower stability is at the whim of bower component authors.
  • introduce maintainable + upgradable ember app specific brocfile filter (396)
  • ember cli now attempts to use the project-local ember-cli if available, this should help with people who have multiple versions of the cli installed. (5a3c9a)
  • Complete restructuring of how ember-cli works internally
  • ember help now offers nicely colored output
  • Extracts initializers autoloading into bower package (#337)
    • locks it to version 0.0.1
  • Introduces broccoli-bower (#333)
    • locks it to version 0.2.0
  • Fix issue where app.js files are appended to tests.js (#347)
  • upgrade broccoli to 0.9.0 v0.9.0 brocfile changes
  • Use configuration from config/environments.js to pass options to Ember.Application.create. (#370)
  • Adds per command help output (#376)
  • Ensures that the broccoli trees are cleaned up properly. (#444)
  • Integrate leek package for ember-cli usage analytics reporting. (#448)
  • Generate current live build to tmp/output/ when running ember server. This is very useful for debugging the current Broccoli tree without manually running ember build. (#457)
  • Added ember test --server to run the testem command line server. ember test --server will automatically re-run your tests after a rebuild. #474
  • Add JSHinting for app/ and test/ trees when building in development. This generates console logs as well as QUnit tests (so that ember test shows failures). #482
  • Use the name specified in package.json while doing ember init. This allows you to use a different application name than your folder name. #491
  • Allow disabling live reload via ember server --live-reload=false. #510


  • Adds ES6 import validation (#209)
  • CSS broccoli fixes (#325)
  • Speed up boot (#273)


  • Makes sure that user cannot create an application named test(#256)
  • Adds broccoli-merge-trees dependency and updates Brocfile to use it
  • Locks blueprint to particular version of ember-cli, broccoli & friends:
    • ember-cli 0.0.21
    • broccoli (v0.7.2)
    • broccoli-es6-concatenator (v0.1.4)
    • broccoli-static-compiler (v0.1.4)
    • broccoli-replace version (v0.1.5)


  • Use loader.js from bower (0c1e8d28)
  • Drops implementation files (54df0288)
  • Drop boilerplate tests (c6f7475e)
  • Use named-amd version of ic-ajax (#225)
  • Separate tests and app code. Tests are now within ‘assets/tests.js’ (#220).
  • Implement --proxy-port and --proxy-host parameters to ember server command (#40)
  • Add support for .ember-cli file to provide default flags to commands (7b90bd9)
  • Ember initializers are required automatically (#242)
  • Supports alternate preprocessors (eg. broccoli-sass vs. broccoli-ruby-sass) (59ddbd)
  • Also exposes registerPlugin method on preprocessor module that allows anyone to register additional plugins (59ddbd)


  • Run tests through /tests.
  • Integrate ember-qunit.
  • Makes sure livereload reports error from watcher (a1d447fe)
  • Support multiple CSS Preprocessors (LESS, Sass and Stylus)
  • upgrade broccoli to 0.5.0.