Add Module Loader runtime objects #1472
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Based on the W3C Module Loader spec: https://whatwg.github.io/loader Includes more or less complete implementations of the runtime objects: %Registry% %RegistryPrototype% %Loader% %LoaderPrototype% %ModuleStatus% %ModuleStatusPrototype% Includes a stub implementation of %Module%. Most of the abstract operations in the spec are implemented completely but we are missing some key ones such as SatisfyInstance. The next step will be to merge the existing ModuleRecord implementation with the ModuleStatus object and set of abstract operations. In particular, this pull request does not plug-in any of the dependency graph resolution or export name resolution because a refactor of existing ModuleRecord code is required. There are some open issues with the code in this change. For example, it's not clear from the spec what we should do if transforming a promise object with a fulfillment handler returns a non-promise object. It seems possible that user code could replace the constructor property on the promise instance which could cause the transformed promise to be anything. Should we throw here? Should we just wrap whatever the object is in a resolved promise? It's not clear. Most of the machinery in the spec requires promise objects so I have taken the approach that we should throw anytime an object is not a promise when we expect it should be.
|
@Yongqu Please take a look over this one, thanks! 😀 |
| BUILTIN(JavascriptLoader, GetterRegistry, EntryGetterRegistry, FunctionInfo::ErrorOnNew) | ||
| BUILTIN(JavascriptLoader, EnsureRegisteredAndEvaluatedFulfillmentHandler, EntryEnsureRegisteredAndEvaluatedFulfillmentHandler, FunctionInfo::ErrorOnNew | FunctionInfo::DoNotProfile) | ||
| BUILTIN(JavascriptLoader, EnsureRegisteredFulfillmentHandler, EntryEnsureRegisteredFulfillmentHandler, FunctionInfo::ErrorOnNew | FunctionInfo::DoNotProfile) | ||
| BUILTIN(JavascriptLoader, EnsureEvaluatedFulfillmentHandler, EntryEnsureEvaluatedFulfillmentHandler, FunctionInfo::ErrorOnNew | FunctionInfo::DoNotProfile) |
There was a problem hiding this comment.
is this an official builtin?
|
|
|
Followed up with @boingoing offline. Seems some design change might render this PR obsolete but salvageable. Adding Waiting label. |
|
Closing this for now, it doesn't appear that we will be implementing this in the near future. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Based on the W3C Module Loader spec:
https://whatwg.github.io/loader
Includes more or less complete implementations of the runtime objects:
%Registry%
%RegistryPrototype%
%Loader%
%LoaderPrototype%
%ModuleStatus%
%ModuleStatusPrototype%
Includes a stub implementation of %Module%.
Most of the abstract operations in the spec are implemented completely but
we are missing some key ones such as SatisfyInstance. The next step will
be to merge the existing ModuleRecord implementation with the ModuleStatus
object and set of abstract operations.
In particular, this pull request does not plug-in any of the dependency
graph resolution or export name resolution because a refactor of existing
ModuleRecord code is required.
There are some open issues with the code in this change. For example, it's
not clear from the spec what we should do if transforming a promise object
with a fulfillment handler returns a non-promise object. It seems possible
that user code could replace the constructor property on the promise
instance which could cause the transformed promise to be anything. Should
we throw here? Should we just wrap whatever the object is in a resolved
promise? It's not clear. Most of the machinery in the spec requires
promise objects so I have taken the approach that we should throw anytime
an object is not a promise when we expect it should be.