rfcs
rfcs copied to clipboard
emberjs
Strict ES Module Support
This RFC is about removing all the vestiges of our system that are not compliant with ES modules. The tl;dr is that require and define need to go away.
As a replacement for some of what people do with those APIs, I also submitted a companion RFC https://github.com/emberjs/rfcs/pull/939 to introduce import.meta.glob.
Converted back to draft because this needs to say a lot more about Resolver.
I was going to ask about this. But also can you shed some light into the implementation aspect of this. I know the RFC does not have to be prescriptive here, but maybe broadly indicate what needs to be done to implement it. Like is the final publishing format going to be ES modules? Or are we still using something AMD-like under the hood, just making it truly an implementation detail by not leaking it? How will importSync be able to work?
FWIW, I just closed https://github.com/emberjs/rfcs/pull/784 in favor of this, but can you maybe also look into the "Motivation" examples in that RFC and see if they are going to be covered by this RFC. You say that require and define will be undefined, but will that also guarantee that any external definition of these (3rd party AMD scripts, node's CJS) will not cause any conflicts anymore?
But also can you shed some light into the implementation aspect of this. I know the RFC does not have to be prescriptive here, but maybe broadly indicate what needs to be done to implement it.
Yes, I think you're right and this RFC in particular really need to explain the impact at both the high-level API layer and the deeper details, because they are currently not hidden very well.
FWIW, I just closed https://github.com/emberjs/rfcs/pull/784 in favor of this, but can you maybe also look into the "Motivation" examples in that RFC and see if they are going to be covered by this RFC. You say that require and define will be undefined, but will that also guarantee that any external definition of these (3rd party AMD scripts, node's CJS) will not cause any conflicts anymore?
Oh yes, this is a very good point. I do think this RFC should solve those problems, and I will make it say something about that explicitly. And that adds some good constraints to the design. It basically means nothing should use shared globals to talk about "the" ember app.
Overall hugely looking forward to this!
I wish we'd pushed towards https://github.com/stefanpenner/ember-strict-resolver ages ago to make this a bit easier for some of the weird edge cases.
I suspect the sometimes tricky details around classic vs pods resolution are one we can probably absorb for now. For models, adapters, and serializers EmberData currently normalizes prior to lookup and has deprecated non-strict lookup strings. There are some exceptions to this normalization though and I'll be sure to look to address those. The general path for EmberData is to stop using the resolver entirely as it is, none of our newer patterns encourage or requires it and even adapters/serializers/models can be made to work without it.
The trickier cases I suspect are things like the normalization of lookup/factoryFor/service strings / keys to module names. It's been valid to pass in AnYcRaezYString and expect to get back matches for an-yc-raez-y-string etc.
This will most likely break the ember inspector dev tools. Is that a blocker for this RFC?
This will most likely break the ember inspector dev tools. Is that a blocker for this RFC?
@Windvis Yep, ember dev tools need to keep working in order for this to move to Released.
I'm a little doubtful this is the right place to comment, but
I ran in to something that this RFC maaaybe unblocks yesterday with @runspired
changes here: https://github.com/NullVoxPopuli/library-provides-web-worker-in-ember-project/pull/1/files
the tl;dr: is that we can't utilize ESM Web Workers (via auto-import in classic builds), unless all of ember-source is non-AMD?
The error from the PR
We are actively working through making ember's internals follow the proposed rules in here as a first step before we finalize the RFC and tell everybody else to update their code in this way.
Thanks but I'm not ready for Accepted stage yet. This needs edits and is still in draft.
To summarize the status: I've been doing the implementation testing for this and think that the importable backward-compatibility modules in this RFC won't work as written due to deadlock concerns.