Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quest: Module Unification #14882

15 of 41 tasks
tomdale opened this issue Jan 27, 2017 · 1 comment
15 of 41 tasks

Quest: Module Unification #14882

tomdale opened this issue Jan 27, 2017 · 1 comment


Copy link

tomdale commented Jan 27, 2017

Quest: Module Unification

This quest issue tracks the high-level tasks needed to complete implementation of the Module Unification RFC in Ember. Module Unification offers both an updated file system layout (based on an updated "pods" structure) as well as a simpler set of rules for how a module must be named, leading to significantly improved application boot time.

Some prior art exists in the 201 Created resolver that implements the Module Unification rules. However, this resolver is designed for maximum compatibility and for testing out the feature; it is not designed to take advantage the performance benefits of the new proposal.

As part of our work building Glimmer-based apps for Monegraph, @dgeb had re-implemented a smaller and more-performant subset of Ember's container, resolver, and registry in TypeScript. We have now open sourced these components under an MIT license and hope they can serve as the basis for Ember. Older semantics that we still need to support can be implemented as a compatibility layer on top of these libraries, so apps that don't need them can get maximum performance.

Those libraries are:



  • Publish to GitHub
  • Publish to npm (at least CommonJS and ES6)
  • Write README
  • Generate API docs


  • Publish to GitHub
  • Publish to npm (at least CommonJS and ES6)
  • Write README
  • Generate API docs


  • Import @glimmer/di package into Ember build
  • Support TypeScript compilation of .ts files in Ember repo
  • Refactor Container to inherit from @glimmer/di
  • Move tests that cover @glimmer/di API to @glimmer/di
  • Container tests passing
  • Refactor Registry to inherit from @glimmer/di
  • Move tests that cover @glimmer/di API to @glimmer/di
  • Registry tests passing
  • Create new ember-module-unification-resolver package with Ember resolver config, inherit from @glimmer/resolver
  • Figure out the fallback mechanism for MU (src/ dir) to ember-cli (app/) to legacy globals resolution. Is this multiple resolvers, or one resolver with fallback implemented internally (likely the latter since this is how it works today where we have fallback).
  • Deprecate default resolver
    • No one relies on App.FooController or Ember.TEMPLATES lookup anymore, we should deprecate these because they add a lot of code and complexity
    • Write deprecation RFC
  • Update Ember-CLI blueprints (generators) to use MU layout
  • Make the new resolver log when ENV.APP.LOG_RESOLVER = true


  • Import @glimmer/resolver into ember-resolver.
  • Update resolver to inherit from @glimmer/resolver
  • For backwards-compatibility, should delegate to old-style resolver rules if something is looked up and not found
  • Should also export a resolver with Module Unification-only rules (import Resolver from "ember-resolver/turbo"?)
  • Release new version on npm

Ember CLI / Build Pipeline

  • Update ember-cli to include new resolver
  • Update app blueprint to use Module Unification-only resolver, with instructions on using old resolver if file system compatibility is needed
  • Update addon blueprint
  • Update build pipeline to consume JS from src/. The app/ tree must also still be read.
  • Update ember-cli-build.js hooks to pass src tree (peer of appTree hooks)
  • Additional Ember CLI build pipeline tasks in Module Unification Epic ember-cli/ember-cli#6332
    • Ember-CLI requires the app/styles directory be present per ember-app.js. This needs to change upstream.
    • In Ember-CLI is too contstraining- it only permits us to look in a single place for index.html for example, when the new resolver rules suggest we should look in src/ui/ first.
    • Templates currently compile with a default export, meaning you can only name them ${name}/${type}.hbs. The compiler needs to know it can export template when the file is just named ${name} (or that it should output to the ${name}/${type} module path).

Developer Ergonomics

  • Integrate MU migration tool into Ember CLI, automatically offer to update apps to the new layout after update
  • Migration tool should update the app to the MU-only resolver once it has rearranged all of the files
  • Lint applications and warn:
    • 1. If the app has an app/ directory but doesn't use the fallback resolver
    • 2. If the app does not have an app/ directory and is still using the slower fallback resolver
Copy link
Sponsor Member

mixonic commented Mar 13, 2018

I'm closing this issue in favor of #16373. The new ticket is better aligned with our current implementation.

@mixonic mixonic closed this as completed Mar 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

4 participants