The Module Unification RFC is all but merged. So this week @iezer @mitchlloyd @bantic and I tried to get the ball rolling. And rolling it is! Two important links:

• We forked the ember-cli/ember-resolver repo to 201-created/dangerously-set-unified-resolver in which a new unified-resolver has been added. You can view a diff of the work. This addon both implements a 100% dynamic version of the module unification rules and gets ember-cli building the src/ dir.
• In 201-created/--new-app-blueprint#with-danger we have a demo application using this addon (you need to npm link the dangerously-set-unified-resolver addon into place). Again you can view a diff of this work, note that the application isn't really doing much.

This implementation works for a proof of concept, however there are several next steps that need to happen before this work is really production ready. Our list, surely missing many important items, follows:

• The addon as written is 100% dynamic. This is probably not going to be great for production, and we will want to do part of this work at compile time on the server. This is changed by picking an appropriate ModuleResolver. It seems ok to ship with the RequireJSModuleResolver and to adopt the precompiled one later.
• Should the resolver simply fail to resolve unknown types silently, or should they be explicitly defined? We've explicitly defined several Ember types (for example -view-registry that seem like they could be handled with general fallback behavior. These issues have been teased out in glimmer-di
• The old resolver tests are failing in our system- not because anything was changed, we just altered the env in some way. @iezer might know more here.
• Ember-CLI requires the app/styles directory be present per ember-app.js. This needs to change upstream. This is tracked in Several fixes for the module unification feature flag #6908
• 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. This is tracked in Several fixes for the module unification feature flag #6908
• The new resolver should be used when an Ember app has a src dir present, however the new resolver should also fall back to the current ember-resolver implementation so you can migrate from the app/ dir to the src/ dir incrementally. Tracked at Implement a fallback resolver ember-resolver#188
• 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). tracked at GlimmerWrapper: Resolve modules without a default export ember-resolver#189
• The resolver is currently accepts a one-time configuration, however addons need an API to add collections and types. This should be as declarative as possible within reason- addons can add setup but cannot introspect the existing config.
• The resolver addon should lint/error on bad filesystem layouts. This needs to be broken down into detailed cases and tests.
• The expandLocalLookup tests should probably be refactored to be more DRY, akin to the basic-dynamic-tests.

Additionally there are a few items needed before actual release:

• Make the new resolver log when ENV.APP.LOG_RESOLVER = true
• Update blueprints to use the new structure
• Need to implement an example addon and support both old and new addon structures. Partially handled via recent work to fallback to old resolver.

Would love thorough review by @dgeb and @rwjblue and others, and I'm sure we should set up some further meetings to figure out a plan.