New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Module Unification Epic #6332
Comments
🙌
|
Darn markdown :-p Thanks @bantic I fixed them inline as well. |
The 3rd bullet about old tests is done. |
A few other tasks:
|
I've added @iezer's comments to the issue description |
@mixonic is it possible to transfer this to an ember-cli RFC or something. It seems like how to implement requires design and discussion. |
@stefanpenner I don't think an RFC would be appropriate for a todo list. I believe @tomdale was going to pick up an implementation RFC per your request. |
@mixonic alright, then it is likely "in addition" to the above list? |
@mixonic Any updates on the progress of this feature? I'm not complaining; I'm just excited to see this feature released |
@dgeb has been pushing this work forward in some other repos- the build-time compilation and such is being experimented with on top of a replacement for the current container. |
Hi folks 👋 I know we are still very early days on all of this work but I wanted to bring up a potential addition to the bullet-point to-do items in this task. Is it worth adding an item to ensure backwards compatibility with SASS file lookup during compilation? For example, if you were to test the current blueprint using the following
I'm assuming this is simply because the broccoli tree of the output of the ember-paper addon is incompatible with the new lookup rules, but I just don't notice a bullet point that covers this eventuality (I could be wrong). |
Closed in favor of emberjs/ember.js#16373 |
The Module Unification RFC is all but merged. So this week @iezer @mitchlloyd @bantic and I tried to get the ball rolling. And rolling it is! Two important links:
unified-resolver
has been added. You can view a diff of the work. This addon both implements a 100% dynamic version of the module unification rules and gets ember-cli building thesrc/
dir.npm link
thedangerously-set-unified-resolver
addon into place). Again you can view a diff of this work, note that the application isn't really doing much.This implementation works for a proof of concept, however there are several next steps that need to happen before this work is really production ready. Our list, surely missing many important items, follows:
The addon as written is 100% dynamic. This is probably not going to be great for production, and we will want to do part of this work at compile time on the server.This is changed by picking an appropriateModuleResolver
. It seems ok to ship with theRequireJSModuleResolver
and to adopt the precompiled one later.Should the resolver simply fail to resolve unknown types silently, or should they be explicitly defined? We've explicitly defined several Ember types (for exampleThese issues have been teased out in glimmer-di-view-registry
that seem like they could be handled with general fallback behavior.Ember-CLI requires theThis is tracked in Several fixes for the module unification feature flag #6908app/styles
directory be present per ember-app.js. This needs to change upstream.In Ember-CLIThis is tracked in Several fixes for the module unification feature flag #6908this.trees.app
is too contstraining- it only permits us to look in a single place forindex.html
for example, when the new resolver rules suggest we should look insrc/ui/
first.The new resolver should be used when an Ember app has aTracked at Implement a fallback resolver ember-resolver#188src
dir present, however the new resolver should also fall back to the currentember-resolver
implementation so you can migrate from theapp/
dir to thesrc/
dir incrementally.Templates currently compile with atracked at GlimmerWrapper: Resolve modules without a default export ember-resolver#189default
export, meaning you can only name them${name}/${type}.hbs
. The compiler needs to know it can exporttemplate
when the file is just named${name}
(or that it should output to the${name}/${type}
module path).expandLocalLookup
tests should probably be refactored to be more DRY, akin to the basic-dynamic-tests.Additionally there are a few items needed before actual release:
Would love thorough review by @dgeb and @rwjblue and others, and I'm sure we should set up some further meetings to figure out a plan.
The text was updated successfully, but these errors were encountered: