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:
For example, this route definition in
app/routes/index.js would result in a
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.
You can also require modules directly with the following syntax:
You can reference a module by using either a relative or absolute path.
If you would like to reference a module using absolute begin
the path with the app name defined in
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
DS (for Ember Data) in your modules you must import them:
One of the enhancements that the new Resolver brings is that it will first look for Pods before the traditional project structure.
Module Directory Naming Structure
||Adapters with the convention
||Components with the convention
||Helpers with the convention
||Initializers with the convention
||Mixins with the convention
||Models with the convention
||Routes with the convention
||Serializers for your models or adapter, where
||Transforms for custom Ember Data attributes, where
||Utility modules with the convention
All modules in the
app directory can be loaded by the resolver but typically
classes such as
utils should be loaded manually with an import statement.
For more information, see Naming Conventions.
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
While previous versions of ember-cli required auto-resolved helpers only if they contain a dash, now all helpers are auto-resolved, regardless of whether they contain a dash or not.
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.
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
section of your project’s
.eslintrc.js file and set its value to true. If you
use the lib in tests, you need to add it to your
tests/.eslintrc.js file, too.