Provides general utility methods when interacting with instances of\nModule, the module variable often seen in CommonJS modules. Accessed\nvia import 'node:module' or require('node:module').
A list of the names of all modules provided by Node.js. Can be used to verify\nif a module is maintained by a third party or not.
\nmodule in this context isn't the same object that's provided\nby the module wrapper. To access it, require the Module module:
// module.mjs\n// In an ECMAScript module\nimport { builtinModules as builtin } from 'node:module';\n// module.cjs\n// In a CommonJS module\nconst builtin = require('node:module').builtinModules;\nimport { createRequire } from 'node:module';\nconst require = createRequire(import.meta.url);\n\n// sibling-module.js is a CommonJS module.\nconst siblingModule = require('./sibling-module');\nimport { isBuiltin } from 'node:module';\nisBuiltin('node:fs'); // true\nisBuiltin('fs'); // true\nisBuiltin('wss'); // false\nIn addition to using the --experimental-loader option in the CLI,\nloaders can be registered programmatically using the\nmodule.register() method.
import { register } from 'node:module';\n\nregister('http-to-https', import.meta.url);\n\n// Because this is a dynamic `import()`, the `http-to-https` hooks will run\n// before importing `./my-app.mjs`.\nawait import('./my-app.mjs');\nIn the example above, we are registering the http-to-https loader,\nbut it will only be available for subsequently imported modules—in\nthis case, my-app.mjs. If the await import('./my-app.mjs') had\ninstead been a static import './my-app.mjs', the app would already\nhave been loaded before the http-to-https hooks were\nregistered. This is part of the design of ES modules, where static\nimports are evaluated from the leaves of the tree first back to the\ntrunk. There can be static imports within my-app.mjs, which\nwill not be evaluated until my-app.mjs is when it's dynamically\nimported.
The --experimental-loader flag of the CLI can be used together\nwith the register function; the loaders registered with the\nfunction will follow the same evaluation chain of loaders registered\nwithin the CLI:
node \\\n --experimental-loader unpkg \\\n --experimental-loader http-to-https \\\n --experimental-loader cache-buster \\\n entrypoint.mjs\n// entrypoint.mjs\nimport { URL } from 'node:url';\nimport { register } from 'node:module';\n\nconst loaderURL = new URL('./my-programmatically-loader.mjs', import.meta.url);\n\nregister(loaderURL);\nawait import('./my-app.mjs');\nThe my-programmatic-loader.mjs can leverage unpkg,\nhttp-to-https, and cache-buster loaders.
It's also possible to use register more than once:
// entrypoint.mjs\nimport { URL } from 'node:url';\nimport { register } from 'node:module';\n\nregister(new URL('./first-loader.mjs', import.meta.url));\nregister('./second-loader.mjs', import.meta.url);\nawait import('./my-app.mjs');\nBoth loaders (first-loader.mjs and second-loader.mjs) can use\nall the resources provided by the loaders registered in the CLI. But\nremember that they will only be available in the next imported\nmodule (my-app.mjs). The evaluation order of the hooks when\nimporting my-app.mjs and consecutive modules in the example above\nwill be:
resolve: second-loader.mjs\nresolve: first-loader.mjs\nresolve: cache-buster\nresolve: http-to-https\nresolve: unpkg\nload: second-loader.mjs\nload: first-loader.mjs\nload: cache-buster\nload: http-to-https\nload: unpkg\nglobalPreload: second-loader.mjs\nglobalPreload: first-loader.mjs\nglobalPreload: cache-buster\nglobalPreload: http-to-https\nglobalPreload: unpkg\nThis function can also be used to pass data to the loader's initialize\nhook; the data passed to the hook may include transferrable objects like ports.
import { register } from 'node:module';\nimport { MessageChannel } from 'node:worker_threads';\n\n// This example showcases how a message channel can be used to\n// communicate to the loader, by sending `port2` to the loader.\nconst { port1, port2 } = new MessageChannel();\n\nport1.on('message', (msg) => {\n console.log(msg);\n});\n\nregister('./my-programmatic-loader.mjs', {\n parentURL: import.meta.url,\n data: { number: 1, port: port2 },\n transferList: [port2],\n});\nThe module.syncBuiltinESMExports() method updates all the live bindings for\nbuiltin ES Modules to match the properties of the CommonJS exports. It\ndoes not add or remove exported names from the ES Modules.
const fs = require('node:fs');\nconst assert = require('node:assert');\nconst { syncBuiltinESMExports } = require('node:module');\n\nfs.readFile = newAPI;\n\ndelete fs.readFileSync;\n\nfunction newAPI() {\n // ...\n}\n\nfs.newAPI = newAPI;\n\nsyncBuiltinESMExports();\n\nimport('node:fs').then((esmFS) => {\n // It syncs the existing readFile property with the new value\n assert.strictEqual(esmFS.readFile, newAPI);\n // readFileSync has been deleted from the required fs\n assert.strictEqual('readFileSync' in fs, false);\n // syncBuiltinESMExports() does not remove readFileSync from esmFS\n assert.strictEqual('readFileSync' in esmFS, true);\n // syncBuiltinESMExports() does not add names\n assert.strictEqual(esmFS.newAPI, undefined);\n});\nHelpers for interacting with the source map cache. This cache is\npopulated when source map parsing is enabled and\nsource map include directives are found in a modules' footer.
\nTo enable source map parsing, Node.js must be run with the flag\n--enable-source-maps, or with code coverage enabled by setting\nNODE_V8_COVERAGE=dir.
// module.mjs\n// In an ECMAScript module\nimport { findSourceMap, SourceMap } from 'node:module';\n// module.cjs\n// In a CommonJS module\nconst { findSourceMap, SourceMap } = require('node:module');\npath is the resolved path for the file for which a corresponding source map\nshould be fetched.
Getter for the payload used to construct the SourceMap instance.
Given a line offset and column offset in the generated source\nfile, returns an object representing the SourceMap range in the\noriginal file if found, or an empty object if not.
\nThe object returned contains the following keys:
\nThe returned value represents the raw range as it appears in the\nSourceMap, based on zero-indexed offsets, not 1-indexed line and\ncolumn numbers as they appear in Error messages and CallSite\nobjects.
\nTo get the corresponding 1-indexed line and column numbers from a\nlineNumber and columnNumber as they are reported by Error stacks\nand CallSite objects, use sourceMap.findOrigin(lineNumber, columnNumber)
Given a 1-indexed lineNumber and columnNumber from a call site in\nthe generated source, find the corresponding call site location\nin the original source.
\nIf the lineNumber and columnNumber provided are not found in any\nsource map, then an empty object is returned. Otherwise, the\nreturned object contains the following keys:
\nCreates a new sourceMap instance.
payload is an object with keys matching the Source map v3 format:
file: <string>version: <number>sources: <string[]>sourcesContent: <string[]>names: <string[]>mappings: <string>sourceRoot: <string>lineLengths is an optional array of the length of each line in the\ngenerated code.