vm: rename vm.Module to vm.SourceTextModule

At the last TC39 meeting, a new type of Module Records backed by
JavaScript source called Dynamic Module Records was discussed, and
it is now at Stage 1. Regardless of whether that proposal makes it
all the way into the spec, SourceTextModule is indeed a more
descriptive and accurate name for what this class represents.

PR-URL: https://github.com/nodejs/node/pull/22007
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Tiancheng "Timothy" Gu <timothygu99@gmail.com>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Jan Krems <jan.krems@gmail.com>
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Michaël Zasso <targos@protonmail.com>
Reviewed-By: Yuta Hiroto <hello@hiroppy.me>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: John-David Dalton <john.david.dalton@gmail.com>
Reviewed-By: Bradley Farias <bradley.meck@gmail.com>

1 files changed, 22 insertions, 22 deletions

diff --git a/doc/api/vm.md b/doc/api/vm.md
index 6c127786a7..e2e3eba0c1 100644
--- a/doc/api/vm.md
+++ b/doc/api/vm.md
@@ -43,7 +43,7 @@ console.log(x); // 1; y is not defined.
 **The vm module is not a security mechanism. Do not use it to run untrusted
 code**.
 
-## Class: vm.Module
+## Class: vm.SourceTextModule
 <!-- YAML
 added: v9.6.0
 -->
@@ -53,20 +53,20 @@ added: v9.6.0
 *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
-specification.
+The `vm.SourceTextModule` 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 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 is fairly
-straightforward.
+Unlike `vm.Script` however, every `vm.SourceTextModule` object is bound to a
+context from its creation. Operations on `vm.SourceTextModule` objects are
+intrinsically asynchronous, in contrast with the synchronous nature of
+`vm.Script` objects. With the help of async functions, however, manipulating
+`vm.SourceTextModule` objects is fairly straightforward.
 
-Using a `vm.Module` object requires four distinct steps: creation/parsing,
-linking, instantiation, and evaluation. These four steps are illustrated in the
-following example.
+Using a `vm.SourceTextModule` object requires four distinct steps:
+creation/parsing, linking, instantiation, and evaluation. These four steps are
+illustrated in the following example.
 
 This implementation lies at a lower level than the [ECMAScript Module
 loader][]. There is also currently no way to interact with the Loader, though
@@ -80,15 +80,15 @@ const contextifiedSandbox = vm.createContext({ secret: 42 });
 (async () => {
   // Step 1
   //
-  // Create a Module by constructing a new `vm.Module` 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
-  // `contextifiedSandbox` as the context this Module belongs to.
+  // 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 `contextifiedSandbox` 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.Module(`
+  const bar = new vm.SourceTextModule(`
     import s from 'foo';
     s;
   `, { context: contextifiedSandbox });
@@ -118,7 +118,7 @@ const contextifiedSandbox = vm.createContext({ secret: 42 });
 
   async function linker(specifier, referencingModule) {
     if (specifier === 'foo') {
-      return new vm.Module(`
+      return new vm.SourceTextModule(`
         // The "secret" variable refers to the global variable we added to
         // "contextifiedSandbox" when creating the context.
         export default secret;
@@ -155,7 +155,7 @@ const contextifiedSandbox = vm.createContext({ secret: 42 });
 })();
 ```
 
-### Constructor: new vm.Module(code[, options])
+### Constructor: new vm.SourceTextModule(code[, options])
 
 * `code` {string} JavaScript Module code to parse
 * `options`
@@ -170,7 +170,7 @@ const contextifiedSandbox = vm.createContext({ secret: 42 });
   * `initalizeImportMeta` {Function} Called during evaluation of this `Module`
     to initialize the `import.meta`. This function has the signature `(meta,
     module)`, where `meta` is the `import.meta` object in the `Module`, and
-    `module` is this `vm.Module` object.
+    `module` is this `vm.SourceTextModule` object.
 
 Creates a new ES `Module` object.
 
@@ -185,7 +185,7 @@ const vm = require('vm');
 const contextifiedSandbox = vm.createContext({ secret: 42 });
 
 (async () => {
-  const module = new vm.Module(
+  const module = new vm.SourceTextModule(
     'Object.getPrototypeOf(import.meta.prop).secret = secret;',
     {
       initializeImportMeta(meta) {