Ember Addon Nomenclature
Letās say youāre browsing through EmberAddons or EmberObserver looking for some new projects that might benefit your application. You stumble across two similar looking addons, Ember-Simple-AuthĀ and Ember-CLI-Simple-Auth. Based on the names alone, what do you think the difference is? Some of you may already know about these projects, but letās say you didnāt. Originally, Ember-Simple-Auth was not an addon at all, and Ember-CLI-Simple-Auth was the addon wrapper that allowed developers to include the main project in their applications. This could be reasonably deduced by the chosen names at one point.
However, now both projects are published as addons; Ember-Simple-Auth supersedes Ember-CLI-Simple-Auth, which is now deprecated after the main project was converted to a full addon. Is that confusing? Maybe, but I think that was a better choice than re-publishing under the Ember-CLI-Simple-Auth name (leaving aside the breaking changes for people using the old packages). Letās look at a few more examples to see what I mean:
Ember-CLI-Deploy
Ember-CLI-Font-Awesome
Ember-CLI-Autoprefixer
Ember-CLI-Release
Ember-Bootstrap
Ember-Table
Ember-Paper
What can we take away from these names? The obvious difference is that some of them are prefixed withĀ āEmber-CLI-ā, and others justĀ āEmber-ā. Does that indicate any commonalities between them? Iād say yes, definitely.Ā
TheĀ āEmber-CLI-ā addons all share a primary goal of adding functionality to your app during builds or from the command line. For example, Ember-CLI-Deploy and Ember-CLI-Release both provide `ember` commands, whereas Ember-CLI-Font-Awesome and Ember-CLI-Autoprefixer are wrappers for third-party code to be included and run with the app.
TheĀ āEmber-ā addons instead aim to provide you with abstractions of reusable Ember objects that might otherwise live within your app. Ember-Bootstrap and Ember-Paper both bring in stylesheets for UI frameworks, and all three provide components to utilize in your projects.
Confusing Addon Names
The point Iām trying to get at is that these addons all use their names meaningfully. This isnāt a new idea, by any means, but there are still projects out there that make the above associations less distinct. Iām not making a dig at the authors of those addons, many of which are quite wonderfully built, but let me show you a few instances:
Ember-CLI-Materialize
Ember-CLI-Notifications
Ember-CLI-Simple-Validation
Ember-Browserify
Ember-Sprite
In these cases, the first three addons all primarily provide components, helpers, services, etc to be consumed within your Ember application. Conversely, Ember-Browserify and Ember-Sprite both affect Broccoliās tree processing to compile files for your app at build time. Any conclusions we had made about naming patterns previously are now shattered by encountering an array of projects that defy those assumptions. To be fair though, some of this naming confusion comes from a time when Ember CLI wasnāt the default path for building Ember Apps, so there are many older addons that carried theĀ āEmber-CLI-ā prefix as a way to differentiate themselves from Ember packages that were not addons at all. Nowadays, addons are the blessed approach to integrating with an Ember app, so itās time for a new tactic.
What I suggest is that we lay out some guidelines for naming addons in order to improve the future ecosystem and make it easier for new developers to tell at a glance what kind of addon theyāre looking at. Some of us have already discussed this idea in the past, but still I feel that its understanding and adoption is not widespread. Iād like to propose three mainĀ ācategoriesā at the moment, though Iām sure with community input we can find even more useful classifications.
Ember-CLI- Addons
Addons that primarily deal with Ember-CLI as opposed to Ember directly should be prefixed with theĀ āEmber-CLI-ā convention. This includes addons that augment the build (such as linters or preprocessors) and those that add new CLI commands, to name a few. Some great examples of these kinds of addons are:
Ember-CLI-ESLint
Ember-CLI-JSDoc
Ember-CLI-SASS
Ember-Data- Addons
Addons whose goal is to provide data adapters for various APIs or other functionality specific to Ember-Data should be prefixed withĀ āEmber-Data-ā. This makes it easy to spot addons that will enhance your data access layer, such as these:
Ember-Data-GitHub
Ember-Data-Route
Ember-Data.Model-Fragments
Ember- Addons
Finally, addons that provide objects that will live in your applications themselves belong in theĀ āEmber-ā category. This includes projects with components, services, helpers, and so on; essentially, any addon that primarily adds files to the `addon/` and `app/` directories deserves this classification. A few of my favorites that follow this pattern are:
Ember-CPM
Ember-Intl
Ember-Moment
Other Addon Types
Obviously, not every addon fits into this pattern. For example, testing addons make up a large chunk of the Ember ecosystem. Perhaps the answer is to create anĀ āEmber-Test-ā prefix for them, but arguably there are cases where it might be semi-redundant, such as Ember-QUnit. There are certainly some niche use-cases that need to be considered carefully, and there are always exceptions to the rule. There are many addons that already follow these conventions, and some addons, such as Ember-Async-Button, were renamed from their original āEmber-CLI-ā prefix to better indicate their purpose. Iām not suggesting that the entire existing ecosphere undergo a renaming revolution all at once, but it is my hope that we can start a broader discussion of this topic and better align our addons with this pattern over time. This is a great path to creating an improved addon community and making Ember even more welcoming to new developers.
