module unification feature flag

Basic support for module unification already exists in Ember. However there are two parts to the functionality that will require minor changes.

Eventually, we want glimmer-di to replace Ember’s container, however blocking module unification on that task seems unwise. Instead, this feature flag is an iterative step that should unblock progress even if the implementation isn’t the exact final form we want it to be in.

This feature flag will exist to flag two pieces of functionality:

• Local lookup. Still under investigation, but there may be minor changes required to properly support local lookup with the Ember resolver API.
• Module unification namespaces, aka support for MU addons. For example, invoking a component as {{my-addon::some-component}} or adding a service dependency as session: Ember.inject.service('my-addon::session').

Supporting MU namespaces

Given a component invoked like so:

{{my-addon::date-picker}}

What do we call lookup with? Today this codepath is blocked by an assertion, but if that assertion is removed Ember would call:

applicationInstance.lookup('template:components/my-addon::date-picker')

This is pretty much nonsense. It could be parsed, but avoiding string parsing and re-mangling is to be avoided. Additionally, adding any other special sigils or syntax to the lookup strings is not desired especially since lookup is itself public API. Once glimmer-di lands, it would be ideal to simply pass a partial specifier. For example:

applicationInstance.lookup({
  type: 'template',
  collection: 'components',
  rootName: 'my-addon',
  name: 'date-picker'
});

However the goal of this feature flag is to continue using the Ember container as it exists today. To avoid adding any public API and avoid messing with strings, a private API on the container is proposed. Something like:

lookupByRootName(applicationInstance, 'template', 'components', 'my-addon::date-picker');

This API can do whatever internal machinations required to get the namespaced my-addon::date-picker string to be a property lookup in the container, and let us move forward with addon support for module unification without adding public API. The serialized path passed to the resolver can be the absolute specifier serialized:

template:/my-addon/components/date-picker

This requires some knowledge in Ember about the module unification config, but that temporary abstraction leak will be eventually plugged by glimmer-di supporting partial specifiers as lookups.

Lastly, whatever current assertions for using :: in component and service names that exist must be moved out of the main Ember codebase. Existing resolvers (Ember’s default resolver and the ember-resolver classic resolver) may need to have assertions added regarding their lack of support for namespaces.

[drewhamlett]

Same here with with latest canary.

This works

 this.route('uploads', { path: '/' }, function() {
    this.route('show', { path: 'uploads/:id' })
  })

This doesn’t

 this.route('uploads', { path: '/' }, function() {
    this.route('show', { path: 'uploads/:id' }, function () {})
  })

I get Uncaught TypeError: Cannot read property 'defaultType' of undefined on the uploads/1 route and on / I get

Assertion Failed: You attempted to define a `{{link-to "uploads.show"}}` but did not pass the parameters required for generating its dynamic segments

[izelnakri]

@kevinansfield @mixonic @rwjblue I just had the same link-to bug on Module unification app:

{{link-to "New Post" "admin.posts.new"}}

Ember v3.3.1, ember-resolver 5.0.1

Assertion Failed: You attempted to define a {{link-to "admin.posts.new"}} but did not pass the parameters required for generating its dynamic segments. Cannot read property ‘defaultType’ of undefined