-
Notifications
You must be signed in to change notification settings - Fork 132
feat(realms): Add support for modules in realms. #41
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
Conversation
TODO: Description.
|
Alright, I think we can land this PR now :) awesome work @andreubotella. @nayeemrmn please take a look as well |
nayeemrmn
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
core/runtime/jsruntime.rs
Outdated
| // TODO(andreubotella): Should preserve_snapshotted_modules be in CreateRealmOptions? | ||
| self.init_extension_js(&realm, None, None)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a problem with using preserve_snapshotted_modules from the runtime options on each realm? Since realms apply the snapshot implicitly and this is just another snapshot option.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really have much of a clear idea at this point of what preserve_snapshotted_modules does in detail or how it's supposed to be used, other than that deno_runtime uses it for node: modules. I don't know if it makes sense to keep the option from runtime initialization.
Edit: The realm creation options let you pass a module loader, which will often be the same as the isolate's (that will be the case for ShadowRealm, for example), but for embedders it need not be (as <iframes> have different module maps in the web). I'm not too sure how that would interact with preserved_snapshotted_modules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It makes all of the deno_<ext>: modules non-importable for users by removing them from the module map, but accepts a list of modules to exempt from that i.e. node: modules in our case. It's a step which is just as applicable to every realm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While trying to understand how the snapshotted modules interact with the embedder-provided module loader, I noticed that currently they are not included at all in the realm's module map:
deno_core/core/runtime/jsruntime.rs
Line 871 in 444a0ae
| // TODO(andreubotella): Should the module map be initialized with snapshotted data? |
(that was added in PR #45, which was split off this one)
I will update this PR to include those snapshotted modules in the module map, and to support preserve_snapshotted_modules.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that should probably be a follow-up PR though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will revert the change that moves the code that handles preserved_snapshotted_modules inside init_extension_js, since it is now a lot clearer to me that it doesn't belong there. I will handle that in new_inner and create_realm in the follow-up PR.
bartlomieju
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
TODO: Detailed description.
This PR is a port of denoland/deno#15760.
Towards #911.