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\nRegister a module that exports hooks that customize Node.js module\nresolution and loading behavior.
\nimport { 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 hooks registered with the\nfunction will follow the same evaluation chain of hooks 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.
\n\nThis API is currently being redesigned and will still change.
\n
To customize the default module resolution, loader hooks can optionally be\nprovided via a --experimental-loader ./loader-name.mjs argument to Node.js.
When hooks are used they apply to each subsequent loader, the entry point, and\nall import calls. They won't apply to require calls; those still follow\nCommonJS rules.
Loaders follow the pattern of --require:
node \\\n --experimental-loader unpkg \\\n --experimental-loader http-to-https \\\n --experimental-loader cache-buster\nThese are called in the following sequence: cache-buster calls\nhttp-to-https which calls unpkg.
Hooks are part of a chain, even if that chain consists of only one custom\n(user-provided) hook and the default hook, which is always present. Hook\nfunctions nest: each one must always return a plain object, and chaining happens\nas a result of each function calling next<hookName>(), which is a reference\nto the subsequent loader's hook.
A hook that returns a value lacking a required property triggers an exception.\nA hook that returns without calling next<hookName>() and without returning\nshortCircuit: true also triggers an exception. These errors are to help\nprevent unintentional breaks in the chain.
Hooks are run in a separate thread, isolated from the main. That means it is a\ndifferent realm. The hooks thread may be\nterminated by the main thread at any time, so do not depend on asynchronous\noperations (like console.log) to complete.
\n\nThe loaders API is being redesigned. This hook may disappear or its\nsignature may change. Do not rely on the API described below.
\n
data <any> The data from register(loader, import.meta.url, { data }).register.The initialize hook provides a way to define a custom function that runs\nin the loader's thread when the loader is initialized. Initialization happens\nwhen the loader is registered via register or registered via the\n--experimental-loader command line option.
This hook can send and receive data from a register invocation, including\nports and other transferrable objects. The return value of initialize must be\neither:
undefined,port.postMessage),Promise resolving to one of the aforementioned values.Loader code:
\n// In the below example this file is referenced as\n// '/path-to-my-loader.js'\n\nexport async function initialize({ number, port }) {\n port.postMessage(`increment: ${number + 1}`);\n return 'ok';\n}\nCaller code:
\nimport assert from 'node:assert';\nimport { 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 between the main (application) thread and the loader\n// running on the loaders thread, by sending `port2` to the loader.\nconst { port1, port2 } = new MessageChannel();\n\nport1.on('message', (msg) => {\n assert.strictEqual(msg, 'increment: 2');\n});\n\nconst result = register('/path-to-my-loader.js', {\n parentURL: import.meta.url,\n data: { number: 1, port: port2 },\n transferList: [port2],\n});\n\nassert.strictEqual(result, 'ok');\n\n\nThe loaders API is being redesigned. This hook may disappear or its\nsignature may change. Do not rely on the API described below.
\n
specifier <string>context <Object>\nconditions <string[]> Export conditions of the relevant package.jsonimportAssertions <Object> An object whose key-value pairs represent the\nassertions for the module to importparentURL <string> | <undefined> The module importing this one, or undefined\nif this is the Node.js entry pointnextResolve <Function> The subsequent resolve hook in the chain, or the\nNode.js default resolve hook after the last user-supplied resolve hook\n\nformat <string> | <null> | <undefined> A hint to the load hook (it might be\nignored)\n'builtin' | 'commonjs' | 'json' | 'module' | 'wasm'importAssertions <Object> | <undefined> The import assertions to use when\ncaching the module (optional; if excluded the input will be used)shortCircuit <undefined> | <boolean> A signal that this hook intends to\nterminate the chain of resolve hooks. Default: falseurl <string> The absolute URL to which this input resolves\n\nCaveat Despite support for returning promises and async functions, calls\nto
\nresolvemay block the main thread which can impact performance.
The resolve hook chain is responsible for telling Node.js where to find and\nhow to cache a given import statement or expression. It can optionally return\nits format (such as 'module') as a hint to the load hook. If a format is\nspecified, the load hook is ultimately responsible for providing the final\nformat value (and it is free to ignore the hint provided by resolve); if\nresolve provides a format, a custom load hook is required even if only to\npass the value to the Node.js default load hook.
Import type assertions are part of the cache key for saving loaded modules into\nthe internal module cache. The resolve hook is responsible for\nreturning an importAssertions object if the module should be cached with\ndifferent assertions than were present in the source code.
The conditions property in context is an array of conditions for\npackage exports conditions that apply to this resolution\nrequest. They can be used for looking up conditional mappings elsewhere or to\nmodify the list when calling the default resolution logic.
The current package exports conditions are always in\nthe context.conditions array passed into the hook. To guarantee default\nNode.js module specifier resolution behavior when calling defaultResolve, the\ncontext.conditions array passed to it must include all elements of the\ncontext.conditions array originally passed into the resolve hook.
export function resolve(specifier, context, nextResolve) {\n const { parentURL = null } = context;\n\n if (Math.random() > 0.5) { // Some condition.\n // For some or all specifiers, do some custom logic for resolving.\n // Always return an object of the form {url: <string>}.\n return {\n shortCircuit: true,\n url: parentURL ?\n new URL(specifier, parentURL).href :\n new URL(specifier).href,\n };\n }\n\n if (Math.random() < 0.5) { // Another condition.\n // When calling `defaultResolve`, the arguments can be modified. In this\n // case it's adding another value for matching conditional exports.\n return nextResolve(specifier, {\n ...context,\n conditions: [...context.conditions, 'another-condition'],\n });\n }\n\n // Defer to the next hook in the chain, which would be the\n // Node.js default resolve if this is the last user-specified loader.\n return nextResolve(specifier);\n}\n\n\nThe loaders API is being redesigned. This hook may disappear or its\nsignature may change. Do not rely on the API described below.
\n
\n\nIn a previous version of this API, this was split across 3 separate, now\ndeprecated, hooks (
\ngetFormat,getSource, andtransformSource).
url <string> The URL returned by the resolve chaincontext <Object>\nconditions <string[]> Export conditions of the relevant package.jsonformat <string> | <null> | <undefined> The format optionally supplied by the\nresolve hook chainimportAssertions <Object>nextLoad <Function> The subsequent load hook in the chain, or the\nNode.js default load hook after the last user-supplied load hook\n\nformat <string>shortCircuit <undefined> | <boolean> A signal that this hook intends to\nterminate the chain of resolve hooks. Default: falsesource <string> | <ArrayBuffer> | <TypedArray> The source for Node.js to evaluateThe load hook provides a way to define a custom method of determining how\na URL should be interpreted, retrieved, and parsed. It is also in charge of\nvalidating the import assertion.
The final value of format must be one of the following:
format | \nDescription | \nAcceptable types for source returned by load | \n
|---|---|---|
'builtin' | \nLoad a Node.js builtin module | \nNot applicable | \n
'commonjs' | \nLoad a Node.js CommonJS module | \n{ string, ArrayBuffer, TypedArray, null, undefined } | \n
'json' | \nLoad a JSON file | \n{ string, ArrayBuffer, TypedArray } | \n
'module' | \nLoad an ES module | \n{ string, ArrayBuffer, TypedArray } | \n
'wasm' | \nLoad a WebAssembly module | \n{ ArrayBuffer, TypedArray } | \n
The value of source is ignored for type 'builtin' because currently it is\nnot possible to replace the value of a Node.js builtin (core) module.
The value of source can be omitted for type 'commonjs'. When a source is\nprovided, all require calls from this module will be processed by the ESM\nloader with registered resolve and load hooks; all require.resolve calls\nfrom this module will be processed by the ESM loader with registered resolve\nhooks; require.extensions and monkey-patching on the CommonJS module loader\nwill not apply. If source is undefined or null, it will be handled by the\nCommonJS module loader and require/require.resolve calls will not go through\nthe registered hooks. This behavior for nullish source is temporary — in the\nfuture, nullish source will not be supported.
The Node.js own load implementation, which is the value of next for the last\nloader in the load chain, returns null for source when format is\n'commonjs' for backward compatibility. Here is an example loader that would\nopt-in to using the non-default behavior:
import { readFile } from 'node:fs/promises';\n\nexport async function load(url, context, nextLoad) {\n const result = await nextLoad(url, context);\n if (result.format === 'commonjs') {\n result.source ??= await readFile(new URL(result.responseURL ?? url));\n }\n return result;\n}\n\n\nCaveat: The ESM
\nloadhook and namespaced exports from CommonJS modules\nare incompatible. Attempting to use them together will result in an empty\nobject from the import. This may be addressed in the future.
\n\nThese types all correspond to classes defined in ECMAScript.
\n
ArrayBuffer object is a SharedArrayBuffer.TypedArray object is a Uint8Array.If the source value of a text-based format (i.e., 'json', 'module')\nis not a string, it is converted to a string using util.TextDecoder.
The load hook provides a way to define a custom method for retrieving the\nsource code of an ES module specifier. This would allow a loader to potentially\navoid reading files from disk. It could also be used to map an unrecognized\nformat to a supported one, for example yaml to module.
export async function load(url, context, nextLoad) {\n const { format } = context;\n\n if (Math.random() > 0.5) { // Some condition\n /*\n For some or all URLs, do some custom logic for retrieving the source.\n Always return an object of the form {\n format: <string>,\n source: <string|buffer>,\n }.\n */\n return {\n format,\n shortCircuit: true,\n source: '...',\n };\n }\n\n // Defer to the next hook in the chain.\n return nextLoad(url);\n}\nIn a more advanced scenario, this can also be used to transform an unsupported\nsource to a supported one (see Examples below).
" }, { "textRaw": "`globalPreload()`", "type": "method", "name": "globalPreload", "meta": { "changes": [ { "version": [ "v18.6.0", "v16.17.0" ], "pr-url": "https://github.com/nodejs/node/pull/42623", "description": "Add support for chaining globalPreload hooks." } ] }, "signatures": [ { "params": [] } ], "desc": "\n\nThis hook will be removed in a future version. Use
\ninitializeinstead.\nWhen a loader has aninitializeexport,globalPreloadwill be ignored.
\n\nIn a previous version of this API, this hook was named\n
\ngetGlobalPreloadCode.
context <Object> Information to assist the preload code\nport <MessagePort>Sometimes it might be necessary to run some code inside of the same global\nscope that the application runs in. This hook allows the return of a string\nthat is run as a sloppy-mode script on startup.
\nSimilar to how CommonJS wrappers work, the code runs in an implicit function\nscope. The only argument is a require-like function that can be used to load\nbuiltins like \"fs\": getBuiltin(request: string).
If the code needs more advanced require features, it has to construct\nits own require using module.createRequire().
export function globalPreload(context) {\n return `\\\nglobalThis.someInjectedProperty = 42;\nconsole.log('I just set some globals!');\n\nconst { createRequire } = getBuiltin('module');\nconst { cwd } = getBuiltin('process');\n\nconst require = createRequire(cwd() + '/<preload>');\n// [...]\n`;\n}\nIn order to allow communication between the application and the loader, another\nargument is provided to the preload code: port. This is available as a\nparameter to the loader hook and inside of the source text returned by the hook.\nSome care must be taken in order to properly call port.ref() and\nport.unref() to prevent a process from being in a state where it won't\nclose normally.
/**\n * This example has the application context send a message to the loader\n * and sends the message back to the application context\n */\nexport function globalPreload({ port }) {\n port.onmessage = (evt) => {\n port.postMessage(evt.data);\n };\n return `\\\n port.postMessage('console.log(\"I went to the Loader and back\");');\n port.onmessage = (evt) => {\n eval(evt.data);\n };\n `;\n}\nThe various loader hooks can be used together to accomplish wide-ranging\ncustomizations of the Node.js code loading and evaluation behaviors.
" } ], "modules": [ { "textRaw": "HTTPS loader", "name": "https_loader", "desc": "In current Node.js, specifiers starting with https:// are experimental (see\nHTTPS and HTTP imports).
The loader below registers hooks to enable rudimentary support for such\nspecifiers. While this may seem like a significant improvement to Node.js core\nfunctionality, there are substantial downsides to actually using this loader:\nperformance is much slower than loading files from disk, there is no caching,\nand there is no security.
\n// https-loader.mjs\nimport { get } from 'node:https';\n\nexport function load(url, context, nextLoad) {\n // For JavaScript to be loaded over the network, we need to fetch and\n // return it.\n if (url.startsWith('https://')) {\n return new Promise((resolve, reject) => {\n get(url, (res) => {\n let data = '';\n res.setEncoding('utf8');\n res.on('data', (chunk) => data += chunk);\n res.on('end', () => resolve({\n // This example assumes all network-provided JavaScript is ES module\n // code.\n format: 'module',\n shortCircuit: true,\n source: data,\n }));\n }).on('error', (err) => reject(err));\n });\n }\n\n // Let Node.js handle all other URLs.\n return nextLoad(url);\n}\n// main.mjs\nimport { VERSION } from 'https://coffeescript.org/browser-compiler-modern/coffeescript.js';\n\nconsole.log(VERSION);\nWith the preceding loader, running\nnode --experimental-loader ./https-loader.mjs ./main.mjs\nprints the current version of CoffeeScript per the module at the URL in\nmain.mjs.
Sources that are in formats Node.js doesn't understand can be converted into\nJavaScript using the load hook.
This is less performant than transpiling source files before running\nNode.js; a transpiler loader should only be used for development and testing\npurposes.
\n// coffeescript-loader.mjs\nimport { readFile } from 'node:fs/promises';\nimport { dirname, extname, resolve as resolvePath } from 'node:path';\nimport { cwd } from 'node:process';\nimport { fileURLToPath, pathToFileURL } from 'node:url';\nimport CoffeeScript from 'coffeescript';\n\nconst baseURL = pathToFileURL(`${cwd()}/`).href;\n\nexport async function load(url, context, nextLoad) {\n if (extensionsRegex.test(url)) {\n // Now that we patched resolve to let CoffeeScript URLs through, we need to\n // tell Node.js what format such URLs should be interpreted as. Because\n // CoffeeScript transpiles into JavaScript, it should be one of the two\n // JavaScript formats: 'commonjs' or 'module'.\n\n // CoffeeScript files can be either CommonJS or ES modules, so we want any\n // CoffeeScript file to be treated by Node.js the same as a .js file at the\n // same location. To determine how Node.js would interpret an arbitrary .js\n // file, search up the file system for the nearest parent package.json file\n // and read its \"type\" field.\n const format = await getPackageType(url);\n // When a hook returns a format of 'commonjs', `source` is ignored.\n // To handle CommonJS files, a handler needs to be registered with\n // `require.extensions` in order to process the files with the CommonJS\n // loader. Avoiding the need for a separate CommonJS handler is a future\n // enhancement planned for ES module loaders.\n if (format === 'commonjs') {\n return {\n format,\n shortCircuit: true,\n };\n }\n\n const { source: rawSource } = await nextLoad(url, { ...context, format });\n // This hook converts CoffeeScript source code into JavaScript source code\n // for all imported CoffeeScript files.\n const transformedSource = coffeeCompile(rawSource.toString(), url);\n\n return {\n format,\n shortCircuit: true,\n source: transformedSource,\n };\n }\n\n // Let Node.js handle all other URLs.\n return nextLoad(url);\n}\n\nasync function getPackageType(url) {\n // `url` is only a file path during the first iteration when passed the\n // resolved url from the load() hook\n // an actual file path from load() will contain a file extension as it's\n // required by the spec\n // this simple truthy check for whether `url` contains a file extension will\n // work for most projects but does not cover some edge-cases (such as\n // extensionless files or a url ending in a trailing space)\n const isFilePath = !!extname(url);\n // If it is a file path, get the directory it's in\n const dir = isFilePath ?\n dirname(fileURLToPath(url)) :\n url;\n // Compose a file path to a package.json in the same directory,\n // which may or may not exist\n const packagePath = resolvePath(dir, 'package.json');\n // Try to read the possibly nonexistent package.json\n const type = await readFile(packagePath, { encoding: 'utf8' })\n .then((filestring) => JSON.parse(filestring).type)\n .catch((err) => {\n if (err?.code !== 'ENOENT') console.error(err);\n });\n // Ff package.json existed and contained a `type` field with a value, voila\n if (type) return type;\n // Otherwise, (if not at the root) continue checking the next directory up\n // If at the root, stop and return false\n return dir.length > 1 && getPackageType(resolvePath(dir, '..'));\n}\n# main.coffee\nimport { scream } from './scream.coffee'\nconsole.log scream 'hello, world'\n\nimport { version } from 'node:process'\nconsole.log \"Brought to you by Node.js version #{version}\"\n# scream.coffee\nexport scream = (str) -> str.toUpperCase()\nWith the preceding loader, running\nnode --experimental-loader ./coffeescript-loader.mjs main.coffee\ncauses main.coffee to be turned into JavaScript after its source code is\nloaded from disk but before Node.js executes it; and so on for any .coffee,\n.litcoffee or .coffee.md files referenced via import statements of any\nloaded file.
The previous two loaders defined load hooks. This is an example of a loader\nthat does its work via the resolve hook. This loader reads an\nimport-map.json file that specifies which specifiers to override to another\nURL (this is a very simplistic implemenation of a small subset of the\n\"import maps\" specification).
// import-map-loader.js\nimport fs from 'node:fs/promises';\n\nconst { imports } = JSON.parse(await fs.readFile('import-map.json'));\n\nexport async function resolve(specifier, context, nextResolve) {\n if (Object.hasOwn(imports, specifier)) {\n return nextResolve(imports[specifier], context);\n }\n\n return nextResolve(specifier, context);\n}\nLet's assume we have these files:
\n// main.js\nimport 'a-module';\n// import-map.json\n{\n \"imports\": {\n \"a-module\": \"./some-module.js\"\n }\n}\n// some-module.js\nconsole.log('some module!');\nIf you run node --experimental-loader ./import-map-loader.js main.js\nthe output will be some module!.
In addition to using the --experimental-loader option in the CLI,\nloaders can also be registered programmatically. You can find\ndetailed information about this process in the documentation page\nfor module.register().