Node.js v21.0.0-v8-canary20230612ebf0bd8986 documentation

Table of contents

Modules: node:module API#

The Module object#

Provides general utility methods when interacting with instances of Module, the module variable often seen in CommonJS modules. Accessed via import 'node:module' or require('node:module').


A list of the names of all modules provided by Node.js. Can be used to verify if a module is maintained by a third party or not.

module in this context isn't the same object that's provided by the module wrapper. To access it, require the Module module:

// module.mjs
// In an ECMAScript module
import { builtinModules as builtin } from 'node:module';// module.cjs
// In a CommonJS module
const builtin = require('node:module').builtinModules;


  • filename <string> | <URL> Filename to be used to construct the require function. Must be a file URL object, file URL string, or absolute path string.
  • Returns: <require> Require function
import { createRequire } from 'node:module';
const require = createRequire(import.meta.url);

// sibling-module.js is a CommonJS module.
const siblingModule = require('./sibling-module'); 


  • moduleName <string> name of the module
  • Returns: <boolean> returns true if the module is builtin else returns false
import { isBuiltin } from 'node:module';
isBuiltin('node:fs'); // true
isBuiltin('fs'); // true
isBuiltin('wss'); // false 


In addition to using the --experimental-loader option in the CLI, loaders can be registered programmatically using the module.register() method.

import { register } from 'node:module';

register('http-to-https', import.meta.url);

// Because this is a dynamic `import()`, the `http-to-https` hooks will run
// before importing `./my-app.mjs`.
await import('./my-app.mjs'); 

In the example above, we are registering the http-to-https loader, but it will only be available for subsequently imported modules—in this case, my-app.mjs. If the await import('./my-app.mjs') had instead been a static import './my-app.mjs', the app would already have been loaded before the http-to-https hooks were registered. This is part of the design of ES modules, where static imports are evaluated from the leaves of the tree first back to the trunk. There can be static imports within my-app.mjs, which will not be evaluated until my-app.mjs is when it's dynamically imported.

The --experimental-loader flag of the CLI can be used together with the register function; the loaders registered with the function will follow the same evaluation chain of loaders registered within the CLI:

node \
  --experimental-loader unpkg \
  --experimental-loader http-to-https \
  --experimental-loader cache-buster \
// entrypoint.mjs
import { URL } from 'node:url';
import { register } from 'node:module';

const loaderURL = new URL('./my-programmatically-loader.mjs', import.meta.url);

await import('./my-app.mjs'); 

The my-programmatic-loader.mjs can leverage unpkg, http-to-https, and cache-buster loaders.

It's also possible to use register more than once:

// entrypoint.mjs
import { URL } from 'node:url';
import { register } from 'node:module';

register(new URL('./first-loader.mjs', import.meta.url));
register('./second-loader.mjs', import.meta.url);
await import('./my-app.mjs'); 

Both loaders (first-loader.mjs and second-loader.mjs) can use all the resources provided by the loaders registered in the CLI. But remember that they will only be available in the next imported module (my-app.mjs). The evaluation order of the hooks when importing my-app.mjs and consecutive modules in the example above will be:

resolve: second-loader.mjs
resolve: first-loader.mjs
resolve: cache-buster
resolve: http-to-https
resolve: unpkg
load: second-loader.mjs
load: first-loader.mjs
load: cache-buster
load: http-to-https
load: unpkg
globalPreload: second-loader.mjs
globalPreload: first-loader.mjs
globalPreload: cache-buster
globalPreload: http-to-https
globalPreload: unpkg 


The module.syncBuiltinESMExports() method updates all the live bindings for builtin ES Modules to match the properties of the CommonJS exports. It does not add or remove exported names from the ES Modules.

const fs = require('node:fs');
const assert = require('node:assert');
const { syncBuiltinESMExports } = require('node:module');

fs.readFile = newAPI;

delete fs.readFileSync;

function newAPI() {
  // ...

fs.newAPI = newAPI;


import('node:fs').then((esmFS) => {
  // It syncs the existing readFile property with the new value
  assert.strictEqual(esmFS.readFile, newAPI);
  // readFileSync has been deleted from the required fs
  assert.strictEqual('readFileSync' in fs, false);
  // syncBuiltinESMExports() does not remove readFileSync from esmFS
  assert.strictEqual('readFileSync' in esmFS, true);
  // syncBuiltinESMExports() does not add names
  assert.strictEqual(esmFS.newAPI, undefined);

Source map v3 support#

Stability: 1 - Experimental

Helpers for interacting with the source map cache. This cache is populated when source map parsing is enabled and source map include directives are found in a modules' footer.

To enable source map parsing, Node.js must be run with the flag --enable-source-maps, or with code coverage enabled by setting NODE_V8_COVERAGE=dir.

// module.mjs
// In an ECMAScript module
import { findSourceMap, SourceMap } from 'node:module';// module.cjs
// In a CommonJS module
const { findSourceMap, SourceMap } = require('node:module');


path is the resolved path for the file for which a corresponding source map should be fetched.

Class: module.SourceMap#

new SourceMap(payload)#

Creates a new sourceMap instance.

payload is an object with keys matching the Source map v3 format:


Getter for the payload used to construct the SourceMap instance.

sourceMap.findEntry(lineNumber, columnNumber)#

Given a line number and column number in the generated source file, returns an object representing the position in the original file. The object returned consists of the following keys: