Wrote a resolver for Ember CLI that supports multiple classes per module

Ember CLI
1

Sooo, I’ve just recently jumped into Ember — and directly into Ember CLI. The thing is awesome, but what has really bugged me from the start is the one-class-per-file convention enforced by the module resolver. I often prefer to deal with a bunch of related classes as a combined unit, and in all likelihood there are many others who share this sentiment.

As a result, I wrote a custom resolver that allows me to group multiple classes into consolidated modules that live on some parent level in the source tree.

If you’re using Ember CLI and grappling with an escalating number of files and endless subdirectories, you might find my Magic Resolver useful: GitHub - bintoro/ember-magic-resolver: Multi-class ES6 modules for Ember.

2

@bintoro - Looks really cool, great job!

Please keep in mind though that this introduces ambiguity into the modules world that previously only existed in globals.

Take the following (completely contrived) example:

app/routes/posts/post-loading.js
app/routes/posts/post/loading.js
app/routes/posts-post/loading.js
app/routes/posts-post-loading.js

These could all end up as a named export of PostsPostLoading, but clearly they are separate things.

This is a problem we have with globals today and therefore things like the ember-routing-named-substates feature cannot be enabled in globals mode due to the resulting route name ambiguity.

3

@rwjblue Even though all of these could indeed be named PostsPostLoading, they would mostly end up in different modules:

app/routes/posts.js
app/routes/posts.js
app/routes/posts-post.js
app/routes/posts-post-loading.js

As evident here, the first two can truly represent a problem. If there’s a PostsPostLoading in app/routes/posts.js, it would match both route:posts/post-loading and route:posts/post/loading.

On the other hand, the last two do not cause conflicts because the module paths diverge after /routes. An export in app/routes/posts-post.js can only be found if the resolution request begins with route:posts-post. That is, only ancestor modules strictly along the full path are searched. The resolver does not turn the full path into a classified name and then search through all possibilities relative to the app root.

So, the situation is not quite comparable to the App.BlahBlahBlah mess. I suppose a “known caveats” section in the readme might be in order that would advise against suffixes such as “-loading” or “-error”. Thanks for pointing this out!