Readers' Questions: "Can I start using Module Unification in my app?"

Is module unification something you can use today in an app? It seems like a lot of the discussion revolves around usage in addons, corner cases, or require using canary versions of Ember.

Yes, Module Unification is something that is currently available through a feature flag, which means that you can try it out today! Feature flags are the way that experimental features are tested in Ember, so use it in production at your own risk, and be aware that its behavior may change before it becomes part of default Ember. Learn more here about the currently available feature flags and how to use them in general.

Module Unification was proposed in RFC 143, and it was a common theme in Roadmap articles. Although there’s a lot to it, some of the most visible benefits are a file structure overhaul and namespaced addons. The new file structure groups things by relationship rather than by type. So, for example, a component’s template and JavaScript file will be in the same folder, together, rather than deep in huge lists of other unrelated templates and JavaScript files. Behind the scenes, Module Unification enables other important work like code splitting and more opportunities for build-time optimizations.

As shown in the 3.1 release blog post, an addon with Module Unification file layout can be generated using the latest CLI version:

npm install -g
MODULE_UNIFICATION=true ember addon my-addon

There’s an open Quest Issue showing how to make an app and migrate existing app. Here’s what it says to do currently, but please refer to the issue for the most up-to-date info:

npm install -g
EMBER_CLI_MODULE_UNIFICATION=true ember g component x-button
# Generates template.hbs and component.js files in the directory src/ui/components/x-button/

A Quest Issue is written when there’s a large task with many pieces, and help is requested from the community to get the job done. Although it’s a huge organization, Ember has no paid staff. All work is done by volunteers or by employees of companies that sponsor some percentage of hours to work on open source. While a lot of progress has been made, there’s more work to do to bring it to the finish line! People interested in helping can comment on the open Quest Issue, drop by the #st-module-unification channel on the Ember Community Slack, or jump into one of the Monday meetings, which are open. There aren’t really any one-hour issues. Contributors should expect to dig in a little in order to help out, and help is welcomed!

P.S. I knew very, very little about Module Unification before writing this! If you want to do more writing but aren’t sure where to start, I recommend picking something you want to learn, versus something you’re already an expert at. There are lots of people who will help you proofread for accuracy, just like I asked a bunch of people for help on this.


Was just wondering about this the other day, thanks @jenweber!


Thank you for this great and detailed write-up, @jenweber!

I have an MU app here if anyone wants to take a look!
mirrored here:


One thing to be aware of is nesting routes more than one level deep does not work with Module Unification today. It should once it’s released, but this was something I ran into experimenting with Module Unification.

1 Like

Do you have an example or even better,. A reproduction?

I created an example app here

To clarify, after starting ember with MODULE_UNIFICATION=true EMBER_CLI_MODULE_UNIFICATION=true ember s, visit http://localhost:4200/levelone works, but http://localhost:4200/levelone/leveltwo and http://localhost:4200/levelone/leveltwo/levelthree do not. However, if you remove the levelthree route, then http://localhost:4200/levelone/leveltwo will work fine.

I added a branch for showing this

Finally, I noticed the error happens as soon as you add a function to the second level. See which has the same error.

1 Like

For all the Googlers: I’ve reported that issue as emberjs/ember.js#17217 and also provided a fix as PR ember-cli/ember-resolver#276.



One additional method is to use the Octane blueprints to generate apps and addons with the MU layout.

ember new my-app -b @ember/octane-app-blueprint
ember g component hola

The Octane blueprint will also include additional packages to support newest features like Glimmer components, tracked properties, native decorators…

At the moment, the blueprint name is actually

ember new my-app -b ember-octane-app-blueprint

But there is a bug. :frowning:


1 Like

Does 3.13 already support this? And would this mean I could already do a pods-like file layout for my app?

AFAIK 3.13 only supports component template co-location, while MU was supposed to be a much larger overhaul of the filesystem layout for an Ember project. MU isn’t really happening (at least as originally conceived) but template co-location is a step in that direction.

So… if your app is running 3.13 and if you enable Octane (or wait for 3.14 when afaik you shouldn’t need to enable anything) you can use pods-style layouts for your components. See the component template co-location RFC for more details on how that looks.