Support module unification

[patricklx]

depends on PR ember-cli/ember-cli#8010

[webark]

hey! that’s so much for this. My main concern, is that it looks like it expects all components to be in a “components” directory, and similar with routes. That’s not going to work for all cases, or for non MU apps.

[patricklx]

hey, yeah I noticed, e.g. pods, (or even custom locations?). Im testing now also with another app

[simonihmig]

I noticed an issue trying this out: styles applied to a nested component do not get picked up. The component does not even receive a class name.

This is because _debugContainerKey, which is used to generate the class name, is behaving weirdly for a nested component in a MU app: say we have a component foo/bar, usually _debugContainerKey would be component:foo/bar, but here it is just component:bar. (I assume this might be a problem in Ember itself, as this is very ambiguous. But obviously this is a private prop, so we can't really rely on it anyway!?)

So in podNames the component is identified as component:my-app@foo/bar while _componentIdentifier() returns component:my-app@bar, making _shouldAddNamespacedClassName() return false.

FWIW, this does not happen in the same (MU) app consuming a classic addon, a nested component there returns component:foo/bar for _debugContainerKey as expected... 🤔

[webark]

yaa.. This is a reason why we are trying to move away from this approach. You can see #300 for a reference of where we are at currently with that. I’m hoping to add MU support to that around the holidays.