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:

• @glimmer/di - Container and registry, resolver interface
• @glimmer/resolver - Implementation of resolver using Module Unification rules

Tasks

@glimmer/di

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

@glimmer/resolver

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

Ember.js

• 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

ember-resolver

• 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 this.trees.app 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