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 [Module Record](https://262.ecma-international.org/14.0/#sec-abstract-module-records) s as defined in the ECMAScript 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. The use of 'async' functions can help with manipulating `vm.Module` objects. Using a `vm.Module` object requires three distinct steps: creation/parsing, linking, and evaluation. These three steps are illustrated in the following example. This implementation lies at a lower level than the `ECMAScript Module loader`. There is also no way to interact with the Loader yet, though support is planned. ```js import vm from 'node:vm'; const contextifiedObject = vm.createContext({ secret: 42, print: console.log, }); // Step 1 // // Create a Module by constructing a new `vm.SourceTextModule` object. This // parses the provided source text, throwing a `SyntaxError` if anything goes // wrong. By default, a Module is created in the top context. But here, we // specify `contextifiedObject` as the context this Module belongs to. // // Here, we attempt to obtain the default export from the module "foo", and // put it into local binding "secret". const bar = new vm.SourceTextModule(` import s from 'foo'; s; print(s); `, { context: contextifiedObject }); // Step 2 // // "Link" the imported dependencies of this Module to it. // // The provided linking callback (the "linker") accepts two arguments: the // parent module (`bar` in this case) and the string that is the specifier of // the imported module. The callback is expected to return a Module that // corresponds to the provided specifier, with certain requirements documented // in `module.link()`. // // If linking has not started for the returned Module, the same linker // callback will be called on the returned Module. // // Even top-level Modules without dependencies must be explicitly linked. The // callback provided would never be called, however. // // The link() method returns a Promise that will be resolved when all the // Promises returned by the linker resolve. // // Note: This is a contrived example in that the linker function creates a new // "foo" module every time it is called. In a full-fledged module system, a // cache would probably be used to avoid duplicated modules. async function linker(specifier, referencingModule) { if (specifier === 'foo') { return new vm.SourceTextModule(` // The "secret" variable refers to the global variable we added to // "contextifiedObject" when creating the context. export default secret; `, { context: referencingModule.context }); // Using `contextifiedObject` instead of `referencingModule.context` // here would work as well. } throw new Error(`Unable to resolve dependency: ${specifier}`); } await bar.link(linker); // Step 3 // // Evaluate the Module. The evaluate() method returns a promise which will // resolve after the module has finished evaluating. // Prints 42. await bar.evaluate(); ```

> [!WARNING] Deno compatibility > The `importModuleDynamically` parameter is not supported. > The `runInContext` method does not support break on `SIGINT`. > Instances of the `vm.Script` class contain precompiled scripts that can be executed in specific contexts.

This feature is only available with the `--experimental-vm-modules` command flag enabled. The `vm.SourceTextModule` class provides the [Source Text Module Record](https://tc39.es/ecma262/#sec-source-text-module-records) as defined in the ECMAScript specification.

This feature is only available with the `--experimental-vm-modules` command flag enabled. The `vm.SyntheticModule` class provides the [Synthetic Module Record](https://heycam.github.io/webidl/#synthetic-module-records) as defined in the WebIDL specification. The purpose of synthetic modules is to provide a generic interface for exposing non-JavaScript sources to ECMAScript module graphs. ```js import vm from 'node:vm'; const source = '{ "a": 1 }'; const module = new vm.SyntheticModule(['default'], function() { const obj = JSON.parse(source); this.setExport('default', obj); }); // Use `module` in linking... ```

Compiles the given code into the provided context (if no context is supplied, the current context is used), and returns it wrapped inside a function with the given `params`.

> [!WARNING] Deno compatibility > The `importModuleDynamically` parameter is not supported. If given a `contextObject`, the `vm.createContext()` method will [prepare that object](https://nodejs.org/docs/latest-v22.x/api/vm.html#what-does-it-mean-to-contextify-an-object) and return a reference to it so that it can be used in `[runInContext](.././node__vm.d.ts/~/runInContext)` or [`script.runInContext()`](https://nodejs.org/docs/latest-v22.x/api/vm.html#scriptrunincontextcontextifiedobject-options). Inside such scripts, the `contextObject` will be the global object, retaining all of its existing properties but also having the built-in objects and functions any standard [global object](https://es5.github.io/#x15.1) has. Outside of scripts run by the vm module, global variables will remain unchanged. ```js import vm from 'node:vm'; global.globalVar = 3; const context = { globalVar: 1 }; vm.createContext(context); vm.runInContext('globalVar *= 2;', context); console.log(context); // Prints: { globalVar: 2 } console.log(global.globalVar); // Prints: 3 ``` If `contextObject` is omitted (or passed explicitly as `undefined`), a new, empty `contextified` object will be returned. The `vm.createContext()` method is primarily useful for creating a single context that can be used to run multiple scripts. For instance, if emulating a web browser, the method can be used to create a single context representing a window's global object, then run all `