Ember CLI has support for:
Using a custom resolver, Ember CLI can automatically import modules when
needed. For example, the route in
routes/post.js will know to use the
controllers/post.js and the template in
You are not limited to automatic resolution so if your application needs to
explicitly include a module, it’s only an
import away. Learn more about ES2015 modules here.
Testing using the CLI
Ember CLI uses two package managers: Bower, for keeping front-end dependencies (including jQuery, Ember, and QUnit) up-to-date, and npm, for managing internal dependencies. You can use both package managers to introduce your own dependencies.
Ember CLI’s runtime is configurable via a file named
.ember-cli. The JSON-formatted file, which must be placed in your home directory, can include any
command-line options whose names must be in camel case form. For example:
Content Security Policy
Ember CLI comes bundled with the ember-cli-content-security-policy addon which when running the development server, enables Content Security Policy in modern browsers. When enabled, Content Security Policy mitigates certain types of attacks including Cross Site Scripting (XSS) and data injection. While browser support is not yet universal, Ember CLI makes it easy to build your app with CSP in mind. For example, enabling it on your production stack is as simple as adding these headers.
Ember CLI is continuously evolving. It’s an on-going 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 (4.0 recommended) and npm (2.x).
The Ember App Kit (now deprecated) project proved to be quite useful. We’ve learned a lot, and it allowed us to iterate quickly while building real ambitious applications.
While it’s initial incarnation was useful, it had several meta problems:
- It was not “simple” and appeared daunting
- Because of inline configuration, the API surface area was massive
- 2 did not allow users to express the “what”, just the “how”. This prevented Ember App Kit from doing more of the heavy lifting itself
- 2 and 3 made 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.