| stage | start-date | release-date | release-versions | teams | prs | project-link | suite | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
accepted |
2024-12-24 00:00:00 UTC |
|
|
<-- Replace "RFC title" with the title of your RFC -->
Since the beginning of ember-cli we have had blueprints available for developers to create new apps, new addons, and a number of different entities for your existing apps such as Components, Routes, Tests, etc. A lesser known feature of the blueprint system is how they are discovered, i.e. when you run ember g component how does ember-cli know how to find the addon that is providing that component blueprint.
This RFC intends to formalise the protocol that ember-cli uses to discover blueprints with a new protocol that will be a lot faster than the previous discovery process and more future proof. This RFC also proposes that we deprecate the old blueprint discovery process.
There are a number of motiviations for this RFC that i will go into in more detail in this section, but for now the main motivators are
- v2 addons have no way to provide blueprints TODO actually check this
- blueprint generation can feel very slow
- there is no clear way to disambiuate blueprints that are being provided by multiple addons
To understand some of the challenges around blueprints loading we have to first understand some of the protocol that ember-cli uses to load addons (specifically non v2 addons). Whenever you run an ember-cli command that needs to have information about addons (such as ember generate or ember serve) ember-cli needs to go through the addon discovery process. This process can be very complicated but a simplified flow might be as follows:
TODO simplified flow of addon discovery
This is the bulk of the RFC.
Explain the design in enough detail for somebody familiar with the framework to understand, and for somebody familiar with the implementation to implement. This should get into specifics and corner-cases, and include examples of how the feature is used. Any new terminology should be defined here.
Please keep in mind any implications within the Ember ecosystem, such as:
- Lint rules (ember-template-lint, eslint-plugin-ember) that should be added, modified or removed
- Features that are replaced or made obsolete by this feature and should eventually be deprecated
- Ember Inspector and debuggability
- Server-side Rendering
- Ember Engines
- The Addon Ecosystem
- IDE Support
- Blueprints that should be added or modified
What names and terminology work best for these concepts and why? How is this idea best presented? As a continuation of existing Ember patterns, or as a wholly new one?
Would the acceptance of this proposal mean the Ember guides must be re-organized or altered? Does it change how Ember is taught to new users at any level?
How should this feature be introduced and taught to existing Ember users?
Keep in mind the variety of learning materials: API docs, guides, blog posts, tutorials, etc.
Why should we not do this? Please consider the impact on teaching Ember, on the integration of this feature with other existing and planned features, on the impact of the API churn on existing apps, etc.
There are tradeoffs to choosing any path, please attempt to identify them here.
What other designs have been considered? What is the impact of not doing this?
This section could also include prior art, that is, how other frameworks in the same domain have solved this problem.
Optional, but suggested for first drafts. What parts of the design are still TBD?