Skip to content

vm: add module support #17560

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.

Sign up for GitHub

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

Closed
devsnek wants to merge 12 commits into from
Closed

vm: add module support #17560

Changes from 1 commit
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
ed99b5c
src: flatten ContextifyContext
devsnek Dec 9, 2017
03f57bf
src: factor out some common functions
TimothyGu Jan 13, 2018
9ed3aa1
vm: add modules
devsnek Jan 14, 2018
e23074f
various improvements
TimothyGu Jan 15, 2018
82dbbb4
Pass referencingModule to linker as well
TimothyGu Jan 15, 2018
1c8c113
More docs
TimothyGu Jan 15, 2018
6fc1780
Better tests; error checking
TimothyGu Jan 15, 2018
f3aeb18
experiment
TimothyGu Jan 15, 2018
fe50b47
Last features
TimothyGu Jan 16, 2018
f4f26f7
--experimental-vm-modules, more tests, etc.
TimothyGu Jan 16, 2018
2ee1411
use safe weak maps
devsnek Jan 22, 2018
dfbd67d
Address comments by Michaël and John-David
TimothyGu Jan 22, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Address comments by Michaël and John-David
  • Loading branch information
@TimothyGu
TimothyGu committed Jan 22, 2018
commit dfbd67dcccd300cbfdfbfc876b39931b299c00c4
23 changes: 13 additions & 10 deletions doc/api/vm.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -50,6 +50,9 @@ added: REPLACEME

> Stability: 1 - Experimental

*This feature is only available with the `--experimental-vm-modules` command
flag enabled.*

The `vm.Module` class provides a low-level interface for using ECMAScript
modules in VM contexts. It is the counterpart of the `vm.Script` class that
closely mirrors [Source Text Module Record][]s as defined in the ECMAScript
Expand All @@ -58,16 +61,13 @@ specification.
Unlike `vm.Script` however, every `vm.Module` object is bound to a context from
its creation. Operations on `vm.Module` objects are intrinsically asynchronous,
in contrast with the synchronous nature of `vm.Script` objects. With the help
of async functions, however, manipulating `vm.Module` objects are fairly
of async functions, however, manipulating `vm.Module` objects is fairly
straightforward.

Using a `vm.Module` object requires four distinct steps: creation/parsing,
linking, instantiating, and evaluation. These four steps are illustrated in the
linking, instantiation, and evaluation. These four steps are illustrated in the
following example.

This feature is only available with the `--experimental-vm-modules` command
flag enabled.

*Note*: This implementation lies at a lower level than the [ECMAScript Module
loader][]. There is also currently no way to interact with the Loader, though
support is planned.
Expand All @@ -89,8 +89,8 @@ const contextifiedSandbox = vm.createContext({ secret: 42 });
// put it into local binding "secret".

const bar = new vm.Module(`
import secret from 'foo';
secret;
import s from 'foo';
s;
`, { context: contextifiedSandbox });

Copy link
Copy Markdown
Member

@jdalton jdalton Jan 22, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can the contextifiedSandbox for the vm.Module assigned to bar be different the one used in the linker call of vm.Module for foo?

Since secret is a global of the contextifiedSandbox it'd make it more clear if it wasn't used for bar but was used for foo (if possible).

Copy link
Copy Markdown
Member Author

@devsnek devsnek Jan 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all modules that are linked together must be in the same context

Copy link
Copy Markdown
Member

@jdalton jdalton Jan 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe doing import s from 'foo' then so it's not the same name as the global.

Copy link
Copy Markdown
Member

@jdalton jdalton Jan 22, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all modules that are linked together must be in the same context

Could the context be made available to the linker as an arg or a this.context so it doesn't have to be passed around as a var from an outer scope.

Copy link
Copy Markdown
Member Author

@devsnek devsnek Jan 22, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't understand what you mean, like (referencing module, specifier, context)? i don't see the benefit of it.

Copy link
Copy Markdown
Member

@jdalton jdalton Jan 22, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the moment you have defined context in an outer scope, but since it's required to be the same anyways it might as well be tracked by the created module so things like the linker will have access to it without needing to have access to the outer scope var.

Copy link
Copy Markdown
Member

@TimothyGu TimothyGu Jan 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe doing import s from 'foo' then so it's not the same name as the global.

👍

At the moment you have to define context in an outer scope, but since it's required to be the same anyways it might as well be tracked by the created module so things like the linker will have access to it without needing to have access to the outer scope var.

The linker function already has access to it through referencingModule.context.

Copy link
Copy Markdown
Member

@jdalton jdalton Jan 22, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The linker function already has access to it through referencingModule.context.

Nice! Can the example be updated to use it.

Copy link
Copy Markdown
Member

@TimothyGu TimothyGu Jan 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.


Expand Down Expand Up @@ -123,7 +123,10 @@ const contextifiedSandbox = vm.createContext({ secret: 42 });
// The "secret" variable refers to the global variable we added to
// "contextifiedSandbox" when creating the context.
export default secret;
`, { context: contextifiedSandbox });
`, { context: referencingModule.context });

// Using `contextifiedSandbox` instead of `referencingModule.context`
// here would work as well.
}
throw new Error(`Unable to resolve dependency: ${specifier}`);
}
Expand All @@ -144,8 +147,8 @@ const contextifiedSandbox = vm.createContext({ secret: 42 });
//
// Evaluate the Module. The evaluate() method returns a Promise with a single
// property "result" that contains the result of the very last statement
// executed in the Module. In the case of `bar`, it is `secret;`, which refers
// to the default export of the `foo` module, the `secret` we set in the
// executed in the Module. In the case of `bar`, it is `s;`, which refers to
// the default export of the `foo` module, the `secret` we set in the
// beginning to 42.

const { result } = await bar.evaluate();
Expand Down