The node:vm module enables compiling and running code within V8 Virtual\nMachine contexts.
The node:vm module is not a security\nmechanism. Do not use it to run untrusted code.
JavaScript code can be compiled and run immediately or\ncompiled, saved, and run later.
\nA common use case is to run the code in a different V8 Context. This means\ninvoked code has a different global object than the invoking code.
\nOne can provide the context by contextifying an\nobject. The invoked code treats any property in the context like a\nglobal variable. Any changes to global variables caused by the invoked\ncode are reflected in the context object.
\nimport { createContext, runInContext } from 'node:vm';\n\nconst x = 1;\n\nconst context = { x: 2 };\ncreateContext(context); // Contextify the object.\n\nconst code = 'x += 40; var y = 17;';\n// `x` and `y` are global variables in the context.\n// Initially, x has the value 2 because that is the value of context.x.\nrunInContext(code, context);\n\nconsole.log(context.x); // 42\nconsole.log(context.y); // 17\n\nconsole.log(x); // 1; y is not defined\nconst { createContext, runInContext } = require('node:vm');\n\nconst x = 1;\n\nconst context = { x: 2 };\ncreateContext(context); // Contextify the object.\n\nconst code = 'x += 40; var y = 17;';\n// `x` and `y` are global variables in the context.\n// Initially, x has the value 2 because that is the value of context.x.\nrunInContext(code, context);\n\nconsole.log(context.x); // 42\nconsole.log(context.y); // 17\n\nconsole.log(x); // 1; y is not defined\nInstances of the vm.Script class contain precompiled scripts that can be\nexecuted in specific contexts.
If options is a string, then it specifies the filename.
Creating a new vm.Script object compiles code but does not run it. The\ncompiled vm.Script can be run later multiple times. The code is not bound to\nany global object; rather, it is bound before each run, just for that run.
When cachedData is supplied to create the vm.Script, this value will be set\nto either true or false depending on acceptance of the data by V8.\nOtherwise the value is undefined.
When the script is compiled from a source that contains a source map magic\ncomment, this property will be set to the URL of the source map.
\nimport vm from 'node:vm';\n\nconst script = new vm.Script(`\nfunction myFunc() {}\n//# sourceMappingURL=sourcemap.json\n`);\n\nconsole.log(script.sourceMapURL);\n// Prints: sourcemap.json\nconst vm = require('node:vm');\n\nconst script = new vm.Script(`\nfunction myFunc() {}\n//# sourceMappingURL=sourcemap.json\n`);\n\nconsole.log(script.sourceMapURL);\n// Prints: sourcemap.json\nCreates a code cache that can be used with the Script constructor's\ncachedData option. Returns a Buffer. This method may be called at any\ntime and any number of times.
The code cache of the Script doesn't contain any JavaScript observable\nstates. The code cache is safe to be saved along side the script source and\nused to construct new Script instances multiple times.
Functions in the Script source can be marked as lazily compiled and they are\nnot compiled at construction of the Script. These functions are going to be\ncompiled when they are invoked the first time. The code cache serializes the\nmetadata that V8 currently knows about the Script that it can use to speed up\nfuture compilations.
const script = new vm.Script(`\nfunction add(a, b) {\n return a + b;\n}\n\nconst x = add(1, 2);\n`);\n\nconst cacheWithoutAdd = script.createCachedData();\n// In `cacheWithoutAdd` the function `add()` is marked for full compilation\n// upon invocation.\n\nscript.runInThisContext();\n\nconst cacheWithAdd = script.createCachedData();\n// `cacheWithAdd` contains fully compiled function `add()`.\nRuns the compiled code contained by the vm.Script object within the given\ncontextifiedObject and returns the result. Running code does not have access\nto local scope.
The following example compiles code that increments a global variable, sets\nthe value of another global variable, then execute the code multiple times.\nThe globals are contained in the context object.
import { createContext, Script } from 'node:vm';\n\nconst context = {\n animal: 'cat',\n count: 2,\n};\n\nconst script = new Script('count += 1; name = \"kitty\";');\n\ncreateContext(context);\nfor (let i = 0; i < 10; ++i) {\n script.runInContext(context);\n}\n\nconsole.log(context);\n// Prints: { animal: 'cat', count: 12, name: 'kitty' }\nconst { createContext, Script } = require('node:vm');\n\nconst context = {\n animal: 'cat',\n count: 2,\n};\n\nconst script = new Script('count += 1; name = \"kitty\";');\n\ncreateContext(context);\nfor (let i = 0; i < 10; ++i) {\n script.runInContext(context);\n}\n\nconsole.log(context);\n// Prints: { animal: 'cat', count: 12, name: 'kitty' }\nUsing the timeout or breakOnSigint options will result in new event loops\nand corresponding threads being started, which have a non-zero performance\noverhead.
This method is a shortcut to script.runInContext(vm.createContext(options), options).\nIt does several things at once:
contextObject is an object, contextifies it with the new context.\nIf contextObject is undefined, creates a new object and contextifies it.\nIf contextObject is vm.constants.DONT_CONTEXTIFY, don't contextify anything.vm.Script object within the created context. The code\ndoes not have access to the scope in which this method is called.The following example compiles code that sets a global variable, then executes\nthe code multiple times in different contexts. The globals are set on and\ncontained within each individual context.
import { constants, Script } from 'node:vm';\n\nconst script = new Script('globalVar = \"set\"');\n\nconst contexts = [{}, {}, {}];\ncontexts.forEach((context) => {\n script.runInNewContext(context);\n});\n\nconsole.log(contexts);\n// Prints: [{ globalVar: 'set' }, { globalVar: 'set' }, { globalVar: 'set' }]\n\n// This would throw if the context is created from a contextified object.\n// constants.DONT_CONTEXTIFY allows creating contexts with ordinary\n// global objects that can be frozen.\nconst freezeScript = new Script('Object.freeze(globalThis); globalThis;');\nconst frozenContext = freezeScript.runInNewContext(constants.DONT_CONTEXTIFY);\nconst { constants, Script } = require('node:vm');\n\nconst script = new Script('globalVar = \"set\"');\n\nconst contexts = [{}, {}, {}];\ncontexts.forEach((context) => {\n script.runInNewContext(context);\n});\n\nconsole.log(contexts);\n// Prints: [{ globalVar: 'set' }, { globalVar: 'set' }, { globalVar: 'set' }]\n\n// This would throw if the context is created from a contextified object.\n// constants.DONT_CONTEXTIFY allows creating contexts with ordinary\n// global objects that can be frozen.\nconst freezeScript = new Script('Object.freeze(globalThis); globalThis;');\nconst frozenContext = freezeScript.runInNewContext(constants.DONT_CONTEXTIFY);\nRuns the compiled code contained by the vm.Script within the context of the\ncurrent global object. Running code does not have access to local scope, but\ndoes have access to the current global object.
The following example compiles code that increments a global variable then\nexecutes that code multiple times:
import { Script } from 'node:vm';\n\nglobal.globalVar = 0;\n\nconst script = new Script('globalVar += 1', { filename: 'myfile.vm' });\n\nfor (let i = 0; i < 1000; ++i) {\n script.runInThisContext();\n}\n\nconsole.log(globalVar);\n\n// 1000\nconst { Script } = require('node:vm');\n\nglobal.globalVar = 0;\n\nconst script = new Script('globalVar += 1', { filename: 'myfile.vm' });\n\nfor (let i = 0; i < 1000; ++i) {\n script.runInThisContext();\n}\n\nconsole.log(globalVar);\n\n// 1000\nThis feature is only available with the --experimental-vm-modules command\nflag enabled.
The vm.Module class provides a low-level interface for using\nECMAScript modules in VM contexts. It is the counterpart of the vm.Script\nclass that closely mirrors Module Records as defined in the ECMAScript\nspecification.
Unlike vm.Script however, every vm.Module object is bound to a context from\nits creation.
Using a vm.Module object requires three distinct steps: creation/parsing,\nlinking, and evaluation. These three steps are illustrated in the following\nexample.
This implementation lies at a lower level than the ECMAScript Module\nloader. There is also no way to interact with the Loader yet, though\nsupport is planned.
\nimport vm from 'node:vm';\n\nconst contextifiedObject = vm.createContext({\n secret: 42,\n print: console.log,\n});\n\n// Step 1\n//\n// Create a Module by constructing a new `vm.SourceTextModule` object. This\n// parses the provided source text, throwing a `SyntaxError` if anything goes\n// wrong. By default, a Module is created in the top context. But here, we\n// specify `contextifiedObject` as the context this Module belongs to.\n//\n// Here, we attempt to obtain the default export from the module \"foo\", and\n// put it into local binding \"secret\".\n\nconst rootModule = new vm.SourceTextModule(`\n import s from 'foo';\n s;\n print(s);\n`, { context: contextifiedObject });\n\n// Step 2\n//\n// \"Link\" the imported dependencies of this Module to it.\n//\n// Obtain the requested dependencies of a SourceTextModule by\n// `sourceTextModule.moduleRequests` and resolve them.\n//\n// Even top-level Modules without dependencies must be explicitly linked. The\n// array passed to `sourceTextModule.linkRequests(modules)` can be\n// empty, however.\n//\n// Note: This is a contrived example in that the resolveAndLinkDependencies\n// creates a new \"foo\" module every time it is called. In a full-fledged\n// module system, a cache would probably be used to avoid duplicated modules.\n\nconst moduleMap = new Map([\n ['root', rootModule],\n]);\n\nfunction resolveAndLinkDependencies(module) {\n const requestedModules = module.moduleRequests.map((request) => {\n // In a full-fledged module system, the resolveAndLinkDependencies would\n // resolve the module with the module cache key `[specifier, attributes]`.\n // In this example, we just use the specifier as the key.\n const specifier = request.specifier;\n\n let requestedModule = moduleMap.get(specifier);\n if (requestedModule === undefined) {\n requestedModule = new vm.SourceTextModule(`\n // The \"secret\" variable refers to the global variable we added to\n // \"contextifiedObject\" when creating the context.\n export default secret;\n `, { context: module.context });\n moduleMap.set(specifier, requestedModule);\n // Resolve the dependencies of the new module as well.\n resolveAndLinkDependencies(requestedModule);\n }\n\n return requestedModule;\n });\n\n module.linkRequests(requestedModules);\n}\n\nresolveAndLinkDependencies(rootModule);\nrootModule.instantiate();\n\n// Step 3\n//\n// Evaluate the Module. The evaluate() method returns a promise which will\n// resolve after the module has finished evaluating.\n\n// Prints 42.\nawait rootModule.evaluate();\nconst vm = require('node:vm');\n\nconst contextifiedObject = vm.createContext({\n secret: 42,\n print: console.log,\n});\n\n(async () => {\n // Step 1\n //\n // Create a Module by constructing a new `vm.SourceTextModule` object. This\n // parses the provided source text, throwing a `SyntaxError` if anything goes\n // wrong. By default, a Module is created in the top context. But here, we\n // specify `contextifiedObject` as the context this Module belongs to.\n //\n // Here, we attempt to obtain the default export from the module \"foo\", and\n // put it into local binding \"secret\".\n\n const rootModule = new vm.SourceTextModule(`\n import s from 'foo';\n s;\n print(s);\n `, { context: contextifiedObject });\n\n // Step 2\n //\n // \"Link\" the imported dependencies of this Module to it.\n //\n // Obtain the requested dependencies of a SourceTextModule by\n // `sourceTextModule.moduleRequests` and resolve them.\n //\n // Even top-level Modules without dependencies must be explicitly linked. The\n // array passed to `sourceTextModule.linkRequests(modules)` can be\n // empty, however.\n //\n // Note: This is a contrived example in that the resolveAndLinkDependencies\n // creates a new \"foo\" module every time it is called. In a full-fledged\n // module system, a cache would probably be used to avoid duplicated modules.\n\n const moduleMap = new Map([\n ['root', rootModule],\n ]);\n\n function resolveAndLinkDependencies(module) {\n const requestedModules = module.moduleRequests.map((request) => {\n // In a full-fledged module system, the resolveAndLinkDependencies would\n // resolve the module with the module cache key `[specifier, attributes]`.\n // In this example, we just use the specifier as the key.\n const specifier = request.specifier;\n\n let requestedModule = moduleMap.get(specifier);\n if (requestedModule === undefined) {\n requestedModule = new vm.SourceTextModule(`\n // The \"secret\" variable refers to the global variable we added to\n // \"contextifiedObject\" when creating the context.\n export default secret;\n `, { context: module.context });\n moduleMap.set(specifier, requestedModule);\n // Resolve the dependencies of the new module as well.\n resolveAndLinkDependencies(requestedModule);\n }\n\n return requestedModule;\n });\n\n module.linkRequests(requestedModules);\n }\n\n resolveAndLinkDependencies(rootModule);\n rootModule.instantiate();\n\n // Step 3\n //\n // Evaluate the Module. The evaluate() method returns a promise which will\n // resolve after the module has finished evaluating.\n\n // Prints 42.\n await rootModule.evaluate();\n})();\nIf the module.status is 'errored', this property contains the exception\nthrown by the module during evaluation. If the status is anything else,\naccessing this property will result in a thrown exception.
The value undefined cannot be used for cases where there is not a thrown\nexception due to possible ambiguity with throw undefined;.
Corresponds to the [[EvaluationError]] field of Cyclic Module Records\nin the ECMAScript specification.
The identifier of the current module, as set in the constructor.
" }, { "textRaw": "Type: {Object}", "name": "namespace", "type": "Object", "desc": "The namespace object of the module. This is only available after linking\n(module.link()) has completed.
Corresponds to the GetModuleNamespace abstract operation in the ECMAScript\nspecification.
" }, { "textRaw": "Type: {string}", "name": "status", "type": "string", "desc": "The current status of the module. Will be one of:
\n'unlinked': module.link() has not yet been called.
'linking': module.link() has been called, but not all Promises returned\nby the linker function have been resolved yet.
'linked': The module has been linked successfully, and all of its\ndependencies are linked, but module.evaluate() has not yet been called.
'evaluating': The module is being evaluated through a module.evaluate() on\nitself or a parent module.
'evaluated': The module has been successfully evaluated.
'errored': The module has been evaluated, but an exception was thrown.
Other than 'errored', this status string corresponds to the specification's\nCyclic Module Record's [[Status]] field. 'errored' corresponds to\n'evaluated' in the specification, but with [[EvaluationError]] set to a\nvalue that is not undefined.
Evaluate the module and its depenendencies. Corresponds to the Evaluate() concrete method field of\nCyclic Module Records in the ECMAScript specification.
\nIf the module is a vm.SourceTextModule, evaluate() must be called after the module has been instantiated;\notherwise evaluate() will return a rejected promise.
For a vm.SourceTextModule, the promise returned by evaluate() may be fulfilled either\nsynchronously or asynchronously:
vm.SourceTextModule has no top-level await in itself or any of its dependencies, the promise will be\nfulfilled synchronously after the module and all its dependencies have been evaluated.\nundefined.module.error.vm.SourceTextModule has top-level await in itself or any of its dependencies, the promise will be\nfulfilled asynchronously after the module and all its dependencies have been evaluated.\nundefined.If the module is a vm.SyntheticModule, evaluate() always returns a promise that fulfills synchronously, see\nthe specification of Evaluate() of a Synthetic Module Record:
evaluateCallback passed to its constructor throws an exception synchronously, evaluate() returns\na promise that will be synchronously rejected with that exception.evaluateCallback does not throw an exception, evaluate() returns a promise that will be\nsynchronously resolved to undefined.The evaluateCallback of a vm.SyntheticModule is executed synchronously within the evaluate() call, and its\nreturn value is discarded. This means if evaluateCallback is an asynchronous function, the promise returned by\nevaluate() will not reflect its asynchronous behavior, and any rejections from an asynchronous\nevaluateCallback will be lost.
evaluate() could also be called again after the module has already been evaluated, in which case:
module.status is 'evaluated'), it will do nothing\nand return a promise that resolves to undefined.module.status is 'errored'), it will re-reject\nthe exception that the initial evaluation resulted in.This method cannot be called while the module is being evaluated (module.status is 'evaluating').
Link module dependencies. This method must be called before evaluation, and\ncan only be called once per module.
\nUse sourceTextModule.linkRequests(modules) and\nsourceTextModule.instantiate() to link modules either synchronously or\nasynchronously.
The function is expected to return a Module object or a Promise that\neventually resolves to a Module object. The returned Module must satisfy the\nfollowing two invariants:
Module.status must not be 'errored'.If the returned Module's status is 'unlinked', this method will be\nrecursively called on the returned Module with the same provided linker\nfunction.
link() returns a Promise that will either get resolved when all linking\ninstances resolve to a valid Module, or rejected if the linker function either\nthrows an exception or returns an invalid Module.
The linker function roughly corresponds to the implementation-defined\nHostResolveImportedModule abstract operation in the ECMAScript\nspecification, with a few key differences:
\nThe actual HostResolveImportedModule implementation used during module\nlinking is one that returns the modules linked during linking. Since at\nthat point all modules would have been fully linked already, the\nHostResolveImportedModule implementation is fully synchronous per\nspecification.
\nCorresponds to the Link() concrete method field of Cyclic Module\nRecords in the ECMAScript specification.
" } ] }, { "textRaw": "Class: `vm.SourceTextModule`", "name": "vm.SourceTextModule", "type": "class", "meta": { "added": [ "v9.6.0" ], "changes": [] }, "stability": 1, "stabilityText": "Experimental", "desc": "This feature is only available with the --experimental-vm-modules command\nflag enabled.
<vm.Module>The vm.SourceTextModule class provides the Source Text Module Record as\ndefined in the ECMAScript specification.
Creates a new SourceTextModule instance.
Properties assigned to the import.meta object that are objects may\nallow the module to access information outside the specified context. Use\nvm.runInContext() to create objects in a specific context.
import vm from 'node:vm';\n\nconst contextifiedObject = vm.createContext({ secret: 42 });\n\nconst module = new vm.SourceTextModule(\n 'Object.getPrototypeOf(import.meta.prop).secret = secret;',\n {\n initializeImportMeta(meta) {\n // Note: this object is created in the top context. As such,\n // Object.getPrototypeOf(import.meta.prop) points to the\n // Object.prototype in the top context rather than that in\n // the contextified object.\n meta.prop = {};\n },\n });\n// The module has an empty `moduleRequests` array.\nmodule.linkRequests([]);\nmodule.instantiate();\nawait module.evaluate();\n\n// Now, Object.prototype.secret will be equal to 42.\n//\n// To fix this problem, replace\n// meta.prop = {};\n// above with\n// meta.prop = vm.runInContext('{}', contextifiedObject);\nconst vm = require('node:vm');\nconst contextifiedObject = vm.createContext({ secret: 42 });\n(async () => {\n const module = new vm.SourceTextModule(\n 'Object.getPrototypeOf(import.meta.prop).secret = secret;',\n {\n initializeImportMeta(meta) {\n // Note: this object is created in the top context. As such,\n // Object.getPrototypeOf(import.meta.prop) points to the\n // Object.prototype in the top context rather than that in\n // the contextified object.\n meta.prop = {};\n },\n });\n // The module has an empty `moduleRequests` array.\n module.linkRequests([]);\n module.instantiate();\n await module.evaluate();\n // Now, Object.prototype.secret will be equal to 42.\n //\n // To fix this problem, replace\n // meta.prop = {};\n // above with\n // meta.prop = vm.runInContext('{}', contextifiedObject);\n})();\nCreates a code cache that can be used with the SourceTextModule constructor's\ncachedData option. Returns a Buffer. This method may be called any number\nof times before the module has been evaluated.
The code cache of the SourceTextModule doesn't contain any JavaScript\nobservable states. The code cache is safe to be saved along side the script\nsource and used to construct new SourceTextModule instances multiple times.
Functions in the SourceTextModule source can be marked as lazily compiled\nand they are not compiled at construction of the SourceTextModule. These\nfunctions are going to be compiled when they are invoked the first time. The\ncode cache serializes the metadata that V8 currently knows about the\nSourceTextModule that it can use to speed up future compilations.
// Create an initial module\nconst module = new vm.SourceTextModule('const a = 1;');\n\n// Create cached data from this module\nconst cachedData = module.createCachedData();\n\n// Create a new module using the cached data. The code must be the same.\nconst module2 = new vm.SourceTextModule('const a = 1;', { cachedData });\nIterates over the dependency graph and returns true if any module in its\ndependencies or this module itself contains top-level await expressions,\notherwise returns false.
The search may be slow if the graph is big enough.
\nThis requires the module to be instantiated first. If the module is not\ninstantiated yet, an error will be thrown.
" }, { "textRaw": "`sourceTextModule.hasTopLevelAwait()`", "name": "hasTopLevelAwait", "type": "method", "meta": { "added": [ "v24.9.0" ], "changes": [] }, "signatures": [ { "params": [], "return": { "textRaw": "Returns: {boolean}", "name": "return", "type": "boolean" } } ], "desc": "Returns whether the module itself contains any top-level await expressions.
This corresponds to the field [[HasTLA]] in Cyclic Module Record in the\nECMAScript specification.
Instantiate the module with the linked requested modules.
\nThis resolves the imported bindings of the module, including re-exported\nbinding names. When there are any bindings that cannot be resolved,\nan error would be thrown synchronously.
\nIf the requested modules include cyclic dependencies, the\nsourceTextModule.linkRequests(modules) method must be called on all\nmodules in the cycle before calling this method.
Link module dependencies. This method must be called before evaluation, and\ncan only be called once per module.
\nThe order of the module instances in the modules array should correspond to the order of\nsourceTextModule.moduleRequests being resolved. If two module requests have the same\nspecifier and import attributes, they must be resolved with the same module instance or an\nERR_MODULE_LINK_MISMATCH would be thrown. For example, when linking requests for this\nmodule:
import foo from 'foo';\nimport source Foo from 'foo';\nThe modules array must contain two references to the same instance, because the two\nmodule requests are identical but in two phases.
If the module has no dependencies, the modules array can be empty.
Users can use sourceTextModule.moduleRequests to implement the host-defined\nHostLoadImportedModule abstract operation in the ECMAScript specification,\nand using sourceTextModule.linkRequests() to invoke specification defined\nFinishLoadingImportedModule, on the module with all dependencies in a batch.
It's up to the creator of the SourceTextModule to determine if the resolution\nof the dependencies is synchronous or asynchronous.
After each module in the modules array is linked, call\nsourceTextModule.instantiate().
The specifiers of all dependencies of this module. The returned array is frozen\nto disallow any changes to it.
\nCorresponds to the [[RequestedModules]] field of Cyclic Module Records in\nthe ECMAScript specification.
The requested import dependencies of this module. The returned array is frozen\nto disallow any changes to it.
\nFor example, given a source text:
\nimport foo from 'foo';\nimport fooAlias from 'foo';\nimport bar from './bar.js';\nimport withAttrs from '../with-attrs.ts' with { arbitraryAttr: 'attr-val' };\nimport source Module from 'wasm-mod.wasm';\nThe value of the sourceTextModule.moduleRequests will be:
[\n {\n specifier: 'foo',\n attributes: {},\n phase: 'evaluation',\n },\n {\n specifier: 'foo',\n attributes: {},\n phase: 'evaluation',\n },\n {\n specifier: './bar.js',\n attributes: {},\n phase: 'evaluation',\n },\n {\n specifier: '../with-attrs.ts',\n attributes: { arbitraryAttr: 'attr-val' },\n phase: 'evaluation',\n },\n {\n specifier: 'wasm-mod.wasm',\n attributes: {},\n phase: 'source',\n },\n];\nThis feature is only available with the --experimental-vm-modules command\nflag enabled.
<vm.Module>The vm.SyntheticModule class provides the Synthetic Module Record as\ndefined in the WebIDL specification. The purpose of synthetic modules is to\nprovide a generic interface for exposing non-JavaScript sources to ECMAScript\nmodule graphs.
import { SyntheticModule } from 'node:vm';\n\nconst source = '{ \"a\": 1 }';\nconst syntheticModule = new SyntheticModule(['default'], function() {\n const obj = JSON.parse(source);\n this.setExport('default', obj);\n});\n\n// Use `syntheticModule` in linking\n(async () => {\n await syntheticModule.link(() => {});\n await syntheticModule.evaluate();\n\n console.log('Default export:', syntheticModule.namespace.default);\n})();\nconst { SyntheticModule } = require('node:vm');\n\nconst source = '{ \"a\": 1 }';\nconst syntheticModule = new SyntheticModule(['default'], function() {\n const obj = JSON.parse(source);\n this.setExport('default', obj);\n});\n\n// Use `syntheticModule` in linking\n(async () => {\n await syntheticModule.link(() => {});\n await syntheticModule.evaluate();\n\n console.log('Default export:', syntheticModule.namespace.default);\n})();\nCreates a new SyntheticModule instance.
Objects assigned to the exports of this instance may allow importers of\nthe module to access information outside the specified context. Use\nvm.runInContext() to create objects in a specific context.
This method sets the module export binding slots with the given value.
\nimport vm from 'node:vm';\n\nconst m = new vm.SyntheticModule(['x'], () => {\n m.setExport('x', 1);\n});\n\nawait m.evaluate();\n\nassert.strictEqual(m.namespace.x, 1);\nconst vm = require('node:vm');\n(async () => {\n const m = new vm.SyntheticModule(['x'], () => {\n m.setExport('x', 1);\n });\n await m.evaluate();\n assert.strictEqual(m.namespace.x, 1);\n})();\n<Object>\nspecifier <string> The specifier of the requested module.attributes <Object> The \"with\" value passed to the\nWithClause in a ImportDeclaration, or an empty object if no value was\nprovided.phase <string> The phase of the requested module (\"source\" or \"evaluation\").A ModuleRequest represents the request to import a module with given import attributes and phase.
When using either script.runInThisContext() or\nvm.runInThisContext(), the code is executed within the current V8 global\ncontext. The code passed to this VM context will have its own isolated scope.
In order to run a simple web server using the node:http module the code passed\nto the context must either call require('node:http') on its own, or have a\nreference to the node:http module passed to it. For instance:
import { runInThisContext } from 'node:vm';\nimport { createRequire } from 'node:module';\n\nconst require = createRequire(import.meta.url);\n\nconst code = `\n((require) => {\n const { createServer } = require('node:http');\n\n createServer((request, response) => {\n response.writeHead(200, { 'Content-Type': 'text/plain' });\n response.end('Hello World\\\\n');\n }).listen(8124);\n\n console.log('Server running at http://127.0.0.1:8124/');\n})`;\n\nrunInThisContext(code)(require);\nconst { runInThisContext } = require('node:vm');\n\nconst code = `\n((require) => {\n const { createServer } = require('node:http');\n\n createServer((request, response) => {\n response.writeHead(200, { 'Content-Type': 'text/plain' });\n response.end('Hello World\\\\n');\n }).listen(8124);\n\n console.log('Server running at http://127.0.0.1:8124/');\n})`;\n\nrunInThisContext(code)(require);\nThe require() in the above case shares the state with the context it is\npassed from. This may introduce risks when untrusted code is executed, e.g.\naltering objects in the context in unwanted ways.
All JavaScript executed within Node.js runs within the scope of a \"context\".\nAccording to the V8 Embedder's Guide:
\n\n\nIn V8, a context is an execution environment that allows separate, unrelated,\nJavaScript applications to run in a single instance of V8. You must explicitly\nspecify the context in which you want any JavaScript code to be run.
\n
When the method vm.createContext() is called with an object, the contextObject argument\nwill be used to wrap the global object of a new instance of a V8 Context\n(if contextObject is undefined, a new object will be created from the current context\nbefore its contextified). This V8 Context provides the code run using the node:vm\nmodule's methods with an isolated global environment within which it can operate.\nThe process of creating the V8 Context and associating it with the contextObject\nin the outer context is what this document refers to as \"contextifying\" the object.
The contextifying would introduce some quirks to the globalThis value in the context.\nFor example, it cannot be frozen, and it is not reference equal to the contextObject\nin the outer context.
import { createContext, runInContext } from 'node:vm';\n\n// An undefined `contextObject` option makes the global object contextified.\nconst context = createContext();\nconsole.log(runInContext('globalThis', context) === context); // false\n// A contextified global object cannot be frozen.\ntry {\n runInContext('Object.freeze(globalThis);', context);\n} catch (e) {\n console.log(`${e.constructor.name}: ${e.message}`); // TypeError: Cannot freeze\n}\nconsole.log(runInContext('globalThis.foo = 1; foo;', context)); // 1\nconst { createContext, runInContext } = require('node:vm');\n\n// An undefined `contextObject` option makes the global object contextified.\nconst context = createContext();\nconsole.log(runInContext('globalThis', context) === context); // false\n// A contextified global object cannot be frozen.\ntry {\n runInContext('Object.freeze(globalThis);', context);\n} catch (e) {\n console.log(`${e.constructor.name}: ${e.message}`); // TypeError: Cannot freeze\n}\nconsole.log(runInContext('globalThis.foo = 1; foo;', context)); // 1\nTo create a context with an ordinary global object and get access to a global proxy in\nthe outer context with fewer quirks, specify vm.constants.DONT_CONTEXTIFY as the\ncontextObject argument.
This constant, when used as the contextObject argument in vm APIs, instructs Node.js to create\na context without wrapping its global object with another object in a Node.js-specific manner.\nAs a result, the globalThis value inside the new context would behave more closely to an ordinary\none.
import { createContext, runInContext, constants } from 'node:vm';\n\n// Use vm.constants.DONT_CONTEXTIFY to freeze the global object.\nconst context = createContext(constants.DONT_CONTEXTIFY);\nrunInContext('Object.freeze(globalThis);', context);\ntry {\n runInContext('bar = 1; bar;', context);\n} catch (e) {\n console.log(`${e.constructor.name}: ${e.message}`); // ReferenceError: bar is not defined\n}\nconst { createContext, runInContext, constants } = require('node:vm');\n\n// Use vm.constants.DONT_CONTEXTIFY to freeze the global object.\nconst context = createContext(constants.DONT_CONTEXTIFY);\nrunInContext('Object.freeze(globalThis);', context);\ntry {\n runInContext('bar = 1; bar;', context);\n} catch (e) {\n console.log(`${e.constructor.name}: ${e.message}`); // ReferenceError: bar is not defined\n}\nWhen vm.constants.DONT_CONTEXTIFY is used as the contextObject argument to vm.createContext(),\nthe returned object is a proxy-like object to the global object in the newly created context with\nfewer Node.js-specific quirks. It is reference equal to the globalThis value in the new context,\ncan be modified from outside the context, and can be used to access built-ins in the new context directly.
import { createContext, runInContext, constants } from 'node:vm';\n\nconst context = createContext(constants.DONT_CONTEXTIFY);\n\n// Returned object is reference equal to globalThis in the new context.\nconsole.log(runInContext('globalThis', context) === context); // true\n\n// Can be used to access globals in the new context directly.\nconsole.log(context.Array); // [Function: Array]\nrunInContext('foo = 1;', context);\nconsole.log(context.foo); // 1\ncontext.bar = 1;\nconsole.log(runInContext('bar;', context)); // 1\n\n// Can be frozen and it affects the inner context.\nObject.freeze(context);\ntry {\n runInContext('baz = 1; baz;', context);\n} catch (e) {\n console.log(`${e.constructor.name}: ${e.message}`); // ReferenceError: baz is not defined\n}\nconst { createContext, runInContext, constants } = require('node:vm');\n\nconst context = createContext(constants.DONT_CONTEXTIFY);\n\n// Returned object is reference equal to globalThis in the new context.\nconsole.log(runInContext('globalThis', context) === context); // true\n\n// Can be used to access globals in the new context directly.\nconsole.log(context.Array); // [Function: Array]\nrunInContext('foo = 1;', context);\nconsole.log(context.foo); // 1\ncontext.bar = 1;\nconsole.log(runInContext('bar;', context)); // 1\n\n// Can be frozen and it affects the inner context.\nObject.freeze(context);\ntry {\n runInContext('baz = 1; baz;', context);\n} catch (e) {\n console.log(`${e.constructor.name}: ${e.message}`); // ReferenceError: baz is not defined\n}\nPromises and async functions can schedule tasks run by the JavaScript\nengine asynchronously. By default, these tasks are run after all JavaScript\nfunctions on the current stack are done executing.\nThis allows escaping the functionality of the timeout and\nbreakOnSigint options.
For example, the following code executed by vm.runInNewContext() with a\ntimeout of 5 milliseconds schedules an infinite loop to run after a promise\nresolves. The scheduled loop is never interrupted by the timeout:
import { runInNewContext } from 'node:vm';\n\nfunction loop() {\n console.log('entering loop');\n while (1) console.log(Date.now());\n}\n\nrunInNewContext(\n 'Promise.resolve().then(() => loop());',\n { loop, console },\n { timeout: 5 },\n);\n// This is printed *before* 'entering infinite loop' (!)\nconsole.log('done executing');\nconst { runInNewContext } = require('node:vm');\n\nfunction loop() {\n console.log('entering loop');\n while (1) console.log(Date.now());\n}\n\nrunInNewContext(\n 'Promise.resolve().then(() => loop());',\n { loop, console },\n { timeout: 5 },\n);\n// This is printed *before* 'entering infinite loop' (!)\nconsole.log('done executing');\nThis can be addressed by passing microtaskMode: 'afterEvaluate' to the code\nthat creates the Context:
import { runInNewContext } from 'node:vm';\n\nfunction loop() {\n while (1) console.log(Date.now());\n}\n\nrunInNewContext(\n 'Promise.resolve().then(() => loop());',\n { loop, console },\n { timeout: 5, microtaskMode: 'afterEvaluate' },\n);\nconst { runInNewContext } = require('node:vm');\n\nfunction loop() {\n while (1) console.log(Date.now());\n}\n\nrunInNewContext(\n 'Promise.resolve().then(() => loop());',\n { loop, console },\n { timeout: 5, microtaskMode: 'afterEvaluate' },\n);\nIn this case, the microtask scheduled through promise.then() will be run\nbefore returning from vm.runInNewContext(), and will be interrupted\nby the timeout functionality. This applies only to code running in a\nvm.Context, so e.g. vm.runInThisContext() does not take this option.
Promise callbacks are entered into the microtask queue of the context in which\nthey were created. For example, if () => loop() is replaced with just loop\nin the above example, then loop will be pushed into the global microtask\nqueue, because it is a function from the outer (main) context, and thus will\nalso be able to escape the timeout.
If asynchronous scheduling functions such as process.nextTick(),\nqueueMicrotask(), setTimeout(), setImmediate(), etc. are made available\ninside a vm.Context, functions passed to them will be added to global queues,\nwhich are shared by all contexts. Therefore, callbacks passed to those functions\nare not controllable through the timeout either.
In 'afterEvaluate' mode, the Context has its own microtask queue, separate\nfrom the global microtask queue used by the outer (main) context. While this\nmode is necessary to enforce timeout and enable breakOnSigint with\nasynchronous tasks, it also makes sharing promises between contexts challenging.
In the example below, a promise is created in the inner context and shared with\nthe outer context. When the outer context await on the promise, the execution\nflow of the outer context is disrupted in a surprising way: the log statement\nis never executed.
import { createContext, runInContext } from 'node:vm';\n\nconst inner_context = createContext({}, { microtaskMode: 'afterEvaluate' });\n\n// runInContext() returns a Promise created in the inner context.\nconst inner_promise = runInContext('Promise.resolve()', inner_context);\n\n// As part of performing `await`, the JavaScript runtime must enqueue a task\n// on the microtask queue of the context where `inner_promise` was created.\n// A task is added on the inner microtask queue, but **it will not be run\n// automatically**: this task will remain pending indefinitely.\n//\n// Since the outer microtask queue is empty, execution in the outer module\n// falls through, and the log statement below is never executed.\nawait inner_promise;\n\nconsole.log('this will NOT be printed');\nconst { createContext, runInContext } = require('node:vm');\n\n// runInContext() returns a Promise created in the inner context.\nconst inner_context = createContext({}, { microtaskMode: 'afterEvaluate' });\n\n(async () => {\n const inner_promise = runInContext('Promise.resolve()', inner_context);\n\n // As part of performing `await`, the JavaScript runtime must enqueue a task\n // on the microtask queue of the context where `inner_promise` was created.\n // A task is added on the inner microtask queue, but **it will not be run\n // automatically**: this task will remain pending indefinitely.\n //\n // Since the outer microtask queue is empty, execution in the outer module\n // falls through, and the log statement below is never executed.\n await inner_promise;\n\n console.log('this will NOT be printed');\n})();\nTo successfully share promises between contexts with different microtask queues,\nit is necessary to ensure that tasks on the inner microtask queue will be run\nwhenever the outer context enqueues a task on the inner microtask queue.
\nThe tasks on the microtask queue of a given context are run whenever\nrunInContext() or SourceTextModule.evaluate() are invoked on a script or\nmodule using this context. In our example, the normal execution flow can be\nrestored by scheduling a second call to runInContext() before await inner_promise.
// Schedule `runInContext()` to manually drain the inner context microtask\n// queue; it will run after the `await` statement below.\nsetImmediate(() => {\n vm.runInContext('', context);\n});\n\nawait inner_promise;\n\nconsole.log('OK');\nNote: Strictly speaking, in this mode, node:vm departs from the letter of\nthe ECMAScript specification for enqueing jobs, by allowing asynchronous\ntasks from different contexts to run in a different order than they were\nenqueued.
The following APIs support an importModuleDynamically option to enable dynamic\nimport() in code compiled by the vm module.
new vm.Scriptvm.compileFunction()new vm.SourceTextModulevm.runInThisContext()vm.runInContext()vm.runInNewContext()vm.createContext()This option is still part of the experimental modules API. We do not recommend\nusing it in a production environment.
", "modules": [ { "textRaw": "When the `importModuleDynamically` option is not specified or undefined", "name": "when_the_`importmoduledynamically`_option_is_not_specified_or_undefined", "type": "module", "desc": "If this option is not specified, or if it's undefined, code containing\nimport() can still be compiled by the vm APIs, but when the compiled code is\nexecuted and it actually calls import(), the result will reject with\nERR_VM_DYNAMIC_IMPORT_CALLBACK_MISSING.
This option is currently not supported for vm.SourceTextModule.
With this option, when an import() is initiated in the compiled code, Node.js\nwould use the default ESM loader from the main context to load the requested\nmodule and return it to the code being executed.
This gives access to Node.js built-in modules such as fs or http\nto the code being compiled. If the code is executed in a different context,\nbe aware that the objects created by modules loaded from the main context\nare still from the main context and not instanceof built-in classes in the\nnew context.
const { Script, constants } = require('node:vm');\nconst script = new Script(\n 'import(\"node:fs\").then(({readFile}) => readFile instanceof Function)',\n { importModuleDynamically: constants.USE_MAIN_CONTEXT_DEFAULT_LOADER });\n\n// false: URL loaded from the main context is not an instance of the Function\n// class in the new context.\nscript.runInNewContext().then(console.log);\nimport { Script, constants } from 'node:vm';\n\nconst script = new Script(\n 'import(\"node:fs\").then(({readFile}) => readFile instanceof Function)',\n { importModuleDynamically: constants.USE_MAIN_CONTEXT_DEFAULT_LOADER });\n\n// false: URL loaded from the main context is not an instance of the Function\n// class in the new context.\nscript.runInNewContext().then(console.log);\nThis option also allows the script or function to load user modules:
\nimport { Script, constants } from 'node:vm';\nimport { resolve } from 'node:path';\nimport { writeFileSync } from 'node:fs';\n\n// Write test.js and test.txt to the directory where the current script\n// being run is located.\nwriteFileSync(resolve(import.meta.dirname, 'test.mjs'),\n 'export const filename = \"./test.json\";');\nwriteFileSync(resolve(import.meta.dirname, 'test.json'),\n '{\"hello\": \"world\"}');\n\n// Compile a script that loads test.mjs and then test.json\n// as if the script is placed in the same directory.\nconst script = new Script(\n `(async function() {\n const { filename } = await import('./test.mjs');\n return import(filename, { with: { type: 'json' } })\n })();`,\n {\n filename: resolve(import.meta.dirname, 'test-with-default.js'),\n importModuleDynamically: constants.USE_MAIN_CONTEXT_DEFAULT_LOADER,\n });\n\n// { default: { hello: 'world' } }\nscript.runInThisContext().then(console.log);\nconst { Script, constants } = require('node:vm');\nconst { resolve } = require('node:path');\nconst { writeFileSync } = require('node:fs');\n\n// Write test.js and test.txt to the directory where the current script\n// being run is located.\nwriteFileSync(resolve(__dirname, 'test.mjs'),\n 'export const filename = \"./test.json\";');\nwriteFileSync(resolve(__dirname, 'test.json'),\n '{\"hello\": \"world\"}');\n\n// Compile a script that loads test.mjs and then test.json\n// as if the script is placed in the same directory.\nconst script = new Script(\n `(async function() {\n const { filename } = await import('./test.mjs');\n return import(filename, { with: { type: 'json' } })\n })();`,\n {\n filename: resolve(__dirname, 'test-with-default.js'),\n importModuleDynamically: constants.USE_MAIN_CONTEXT_DEFAULT_LOADER,\n });\n\n// { default: { hello: 'world' } }\nscript.runInThisContext().then(console.log);\nThere are a few caveats with loading user modules using the default loader\nfrom the main context:
\nfilename option passed\nto vm.Script or vm.compileFunction(). The resolution can work with a\nfilename that's either an absolute path or a URL string. If filename is\na string that's neither an absolute path or a URL, or if it's undefined,\nthe resolution will be relative to the current working directory\nof the process. In the case of vm.createContext(), the resolution is always\nrelative to the current working directory since this option is only used when\nthere isn't a referrer script or module.filename that resolves to a specific path, once the process\nmanages to load a particular module from that path, the result may be cached,\nand subsequent load of the same module from the same path would return the\nsame thing. If the filename is a URL string, the cache would not be hit\nif it has different search parameters. For filenames that are not URL\nstrings, there is currently no way to bypass the caching behavior.When importModuleDynamically is a function, it will be invoked when import()\nis called in the compiled code for users to customize how the requested module\nshould be compiled and evaluated. Currently, the Node.js instance must be\nlaunched with the --experimental-vm-modules flag for this option to work. If\nthe flag isn't set, this callback will be ignored. If the code evaluated\nactually calls to import(), the result will reject with\nERR_VM_DYNAMIC_IMPORT_CALLBACK_MISSING_FLAG.
The callback importModuleDynamically(specifier, referrer, importAttributes)\nhas the following signature:
specifier <string> specifier passed to import()referrer <vm.Script> | <Function> | <vm.SourceTextModule> | <Object>\nThe referrer is the compiled vm.Script for new vm.Script,\nvm.runInThisContext, vm.runInContext and vm.runInNewContext. It's the\ncompiled Function for vm.compileFunction, the compiled\nvm.SourceTextModule for new vm.SourceTextModule, and the context Object\nfor vm.createContext().importAttributes <Object> The \"with\" value passed to the\noptionsExpression optional parameter, or an empty object if no value was\nprovided.phase <string> The phase of the dynamic import (\"source\" or \"evaluation\").<Module Namespace Object> | <vm.Module> Returning a vm.Module is\nrecommended in order to take advantage of error tracking, and to avoid issues\nwith namespaces that contain then function exports.// This script must be run with --experimental-vm-modules.\nimport { Script, SyntheticModule } from 'node:vm';\n\nconst script = new Script('import(\"foo.json\", { with: { type: \"json\" } })', {\n async importModuleDynamically(specifier, referrer, importAttributes) {\n console.log(specifier); // 'foo.json'\n console.log(referrer); // The compiled script\n console.log(importAttributes); // { type: 'json' }\n const m = new SyntheticModule(['bar'], () => { });\n await m.link(() => { });\n m.setExport('bar', { hello: 'world' });\n return m;\n },\n});\nconst result = await script.runInThisContext();\nconsole.log(result); // { bar: { hello: 'world' } }\n// This script must be run with --experimental-vm-modules.\nconst { Script, SyntheticModule } = require('node:vm');\n\n(async function main() {\n const script = new Script('import(\"foo.json\", { with: { type: \"json\" } })', {\n async importModuleDynamically(specifier, referrer, importAttributes) {\n console.log(specifier); // 'foo.json'\n console.log(referrer); // The compiled script\n console.log(importAttributes); // { type: 'json' }\n const m = new SyntheticModule(['bar'], () => { });\n await m.link(() => { });\n m.setExport('bar', { hello: 'world' });\n return m;\n },\n });\n const result = await script.runInThisContext();\n console.log(result); // { bar: { hello: 'world' } }\n})();\nCompiles the given code into the provided context (if no context is\nsupplied, the current context is used), and returns it wrapped inside a\nfunction with the given params.
If the given contextObject is an object, the vm.createContext() method will prepare that\nobject and return a reference to it so that it can be used in\ncalls to vm.runInContext() or script.runInContext(). Inside such\nscripts, the global object will be wrapped by the contextObject, retaining all of its\nexisting properties but also having the built-in objects and functions any\nstandard global object has. Outside of scripts run by the vm module, global\nvariables will remain unchanged.
import { createContext, runInContext } from 'node:vm';\n\nglobal.globalVar = 3;\n\nconst context = { globalVar: 1 };\ncreateContext(context);\n\nrunInContext('globalVar *= 2;', context);\n\nconsole.log(context);\n// Prints: { globalVar: 2 }\n\nconsole.log(global.globalVar);\n// Prints: 3\nconst { createContext, runInContext } = require('node:vm');\n\nglobal.globalVar = 3;\n\nconst context = { globalVar: 1 };\ncreateContext(context);\n\nrunInContext('globalVar *= 2;', context);\n\nconsole.log(context);\n// Prints: { globalVar: 2 }\n\nconsole.log(global.globalVar);\n// Prints: 3\nIf contextObject is omitted (or passed explicitly as undefined), a new,\nempty contextified object will be returned.
When the global object in the newly created context is contextified, it has some quirks\ncompared to ordinary global objects. For example, it cannot be frozen. To create a context\nwithout the contextifying quirks, pass vm.constants.DONT_CONTEXTIFY as the contextObject\nargument. See the documentation of vm.constants.DONT_CONTEXTIFY for details.
The vm.createContext() method is primarily useful for creating a single\ncontext that can be used to run multiple scripts. For instance, if emulating a\nweb browser, the method can be used to create a single context representing a\nwindow's global object, then run all <script> tags together within that\ncontext.
The provided name and origin of the context are made visible through the\nInspector API.
Returns true if the given object object has been contextified using\nvm.createContext(), or if it's the global object of a context created\nusing vm.constants.DONT_CONTEXTIFY.
Measure the memory known to V8 and used by all contexts known to the\ncurrent V8 isolate, or the main context.
\nThe format of the object that the returned Promise may resolve with is\nspecific to the V8 engine and may change from one version of V8 to the next.
\nThe returned result is different from the statistics returned by\nv8.getHeapSpaceStatistics() in that vm.measureMemory() measure the\nmemory reachable by each V8 specific contexts in the current instance of\nthe V8 engine, while the result of v8.getHeapSpaceStatistics() measure\nthe memory occupied by each heap space in the current V8 instance.
import { createContext, measureMemory } from 'node:vm';\n// Measure the memory used by the main context.\nmeasureMemory({ mode: 'summary' })\n // This is the same as vm.measureMemory()\n .then((result) => {\n // The current format is:\n // {\n // total: { jsMemoryEstimate: 1601828, jsMemoryRange: [1601828, 5275288] },\n // WebAssembly: { code: 0, metadata: 33962 },\n // }\n console.log(result);\n });\n\nconst context = createContext({ a: 1 });\nmeasureMemory({ mode: 'detailed', execution: 'eager' }).then((result) => {\n // Reference the context here so that it won't be GC'ed\n // until the measurement is complete.\n console.log('Context:', context.a);\n // {\n // total: { jsMemoryEstimate: 1767100, jsMemoryRange: [1767100, 5440560] },\n // WebAssembly: { code: 0, metadata: 33962 },\n // current: { jsMemoryEstimate: 1601828, jsMemoryRange: [1601828, 5275288] },\n // other: [{ jsMemoryEstimate: 165272, jsMemoryRange: [Array] }],\n // }\n console.log(result);\n});\nconst { createContext, measureMemory } = require('node:vm');\n// Measure the memory used by the main context.\nmeasureMemory({ mode: 'summary' })\n // This is the same as vm.measureMemory()\n .then((result) => {\n // The current format is:\n // {\n // total: { jsMemoryEstimate: 1601828, jsMemoryRange: [1601828, 5275288] },\n // WebAssembly: { code: 0, metadata: 33962 },\n // }\n console.log(result);\n });\n\nconst context = createContext({ a: 1 });\nmeasureMemory({ mode: 'detailed', execution: 'eager' }).then((result) => {\n // Reference the context here so that it won't be GC'ed\n // until the measurement is complete.\n console.log('Context:', context.a);\n // {\n // total: { jsMemoryEstimate: 1767100, jsMemoryRange: [1767100, 5440560] },\n // WebAssembly: { code: 0, metadata: 33962 },\n // current: { jsMemoryEstimate: 1601828, jsMemoryRange: [1601828, 5275288] },\n // other: [{ jsMemoryEstimate: 165272, jsMemoryRange: [Array] }],\n // }\n console.log(result);\n});\nThe vm.runInContext() method compiles code, runs it within the context of\nthe contextifiedObject, then returns the result. Running code does not have\naccess to the local scope. The contextifiedObject object must have been\npreviously contextified using the vm.createContext() method.
If options is a string, then it specifies the filename.
The following example compiles and executes different scripts using a single\ncontextified object:
\nimport { createContext, runInContext } from 'node:vm';\n\nconst contextObject = { globalVar: 1 };\ncreateContext(contextObject);\n\nfor (let i = 0; i < 10; ++i) {\n runInContext('globalVar *= 2;', contextObject);\n}\nconsole.log(contextObject);\n// Prints: { globalVar: 1024 }\nconst { createContext, runInContext } = require('node:vm');\n\nconst contextObject = { globalVar: 1 };\ncreateContext(contextObject);\n\nfor (let i = 0; i < 10; ++i) {\n runInContext('globalVar *= 2;', contextObject);\n}\nconsole.log(contextObject);\n// Prints: { globalVar: 1024 }\nThis method is a shortcut to\n(new vm.Script(code, options)).runInContext(vm.createContext(options), options).\nIf options is a string, then it specifies the filename.
It does several things at once:
\ncontextObject is an object, contextifies it with the new context.\nIf contextObject is undefined, creates a new object and contextifies it.\nIf contextObject is vm.constants.DONT_CONTEXTIFY, don't contextify anything.vm.ScriptThe following example compiles and executes code that increments a global\nvariable and sets a new one. These globals are contained in the contextObject.
import { runInNewContext, constants } from 'node:vm';\n\nconst contextObject = {\n animal: 'cat',\n count: 2,\n};\n\nrunInNewContext('count += 1; name = \"kitty\"', contextObject);\nconsole.log(contextObject);\n// Prints: { animal: 'cat', count: 3, name: 'kitty' }\n\n// This would throw if the context is created from a contextified object.\n// vm.constants.DONT_CONTEXTIFY allows creating contexts with ordinary global objects that\n// can be frozen.\nconst frozenContext = runInNewContext(\n 'Object.freeze(globalThis); globalThis;',\n constants.DONT_CONTEXTIFY,\n);\nconst { runInNewContext, constants } = require('node:vm');\n\nconst contextObject = {\n animal: 'cat',\n count: 2,\n};\n\nrunInNewContext('count += 1; name = \"kitty\"', contextObject);\nconsole.log(contextObject);\n// Prints: { animal: 'cat', count: 3, name: 'kitty' }\n\n// This would throw if the context is created from a contextified object.\n// vm.constants.DONT_CONTEXTIFY allows creating contexts with ordinary global objects that\n// can be frozen.\nconst frozenContext = runInNewContext(\n 'Object.freeze(globalThis); globalThis;',\n constants.DONT_CONTEXTIFY,\n);\nvm.runInThisContext() compiles code, runs it within the context of the\ncurrent global and returns the result. Running code does not have access to\nlocal scope, but does have access to the current global object.
If options is a string, then it specifies the filename.
The following example illustrates using both vm.runInThisContext() and\nthe JavaScript eval() function to run the same code:
import { runInThisContext } from 'node:vm';\nlet localVar = 'initial value';\n\nconst vmResult = runInThisContext('localVar = \"vm\";');\nconsole.log(`vmResult: '${vmResult}', localVar: '${localVar}'`);\n// Prints: vmResult: 'vm', localVar: 'initial value'\n\nconst evalResult = eval('localVar = \"eval\";');\nconsole.log(`evalResult: '${evalResult}', localVar: '${localVar}'`);\n// Prints: evalResult: 'eval', localVar: 'eval'\nconst { runInThisContext } = require('node:vm');\nlet localVar = 'initial value';\n\nconst vmResult = runInThisContext('localVar = \"vm\";');\nconsole.log(`vmResult: '${vmResult}', localVar: '${localVar}'`);\n// Prints: vmResult: 'vm', localVar: 'initial value'\n\nconst evalResult = eval('localVar = \"eval\";');\nconsole.log(`evalResult: '${evalResult}', localVar: '${localVar}'`);\n// Prints: evalResult: 'eval', localVar: 'eval'\nBecause vm.runInThisContext() does not have access to the local scope,\nlocalVar is unchanged. In contrast, a direct eval() call does have access\nto the local scope, so the value localVar is changed. In this way\nvm.runInThisContext() is much like an indirect eval() call, e.g.\n(0,eval)('code').
Returns an object containing commonly used constants for VM operations.
", "properties": [ { "textRaw": "`vm.constants.USE_MAIN_CONTEXT_DEFAULT_LOADER`", "name": "USE_MAIN_CONTEXT_DEFAULT_LOADER", "type": "property", "meta": { "added": [ "v21.7.0", "v20.12.0" ], "changes": [] }, "stability": 1.1, "stabilityText": "Active development", "desc": "A constant that can be used as the importModuleDynamically option to\nvm.Script and vm.compileFunction() so that Node.js uses the default\nESM loader from the main context to load the requested module.
For detailed information, see\nSupport of dynamic import() in compilation APIs.