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


#1

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 https://github.com/ember-cli/ember-cli.git
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 https://github.com/ember-cli/ember-cli.git
MODULE_UNIFICATION=true EMBER_CLI_MODULE_UNIFICATION=true ember new my-app
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.


#2

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


#3

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


#4

I have an MU app here if anyone wants to take a look! https://gitlab.com/NullVoxPopuli/emberclear/blob/master/packages/frontend/
mirrored here:
https://github.com/NullVoxPopuli/emberclear/tree/master/packages/frontend