Node.js v26.1.0 documentation

Modules: node:module API#

The Module object#

• Type: <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').

module.builtinModules#

• Type: <string[]>

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;
javascriptcopy

module.createRequire(filename)#

• 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');
mjscopy

module.findPackageJSON(specifier[, base])#

• specifier <string> | <URL> The specifier for the module whose package.json to retrieve. When passing a bare specifier, the package.json at the root of the package is returned. When passing a relative specifier or an absolute specifier, the closest parent package.json is returned.
• base <string> | <URL> The absolute location (file: URL string or FS path) of the containing module. For CJS, use __filename (not __dirname!); for ESM, use import.meta.url. You do not need to pass it if specifier is an absolute specifier.
• Returns: <string> | <undefined> A path if the package.json is found. When specifier is a package, the package's root package.json; when a relative or unresolved, the closest package.json to the specifier.

Caveat: Do not use this to try to determine module format. There are many things affecting that determination; the type field of package.json is the least definitive (ex file extension supersedes it, and a loader hook supersedes that).

Caveat: This currently leverages only the built-in default resolver; if resolve customization hooks are registered, they will not affect the resolution. This may change in the future.

// /path/to/project/packages/bar/bar.js
import { findPackageJSON } from 'node:module';

findPackageJSON('..', import.meta.url);
// '/path/to/project/package.json'
// Same result when passing an absolute specifier instead:
findPackageJSON(new URL('../', import.meta.url));
findPackageJSON(import.meta.resolve('../'));

findPackageJSON('some-package', import.meta.url);
// '/path/to/project/packages/bar/node_modules/some-package/package.json'
// When passing an absolute specifier, you might get a different result if the
// resolved module is inside a subfolder that has nested `package.json`.
findPackageJSON(import.meta.resolve('some-package'));
// '/path/to/project/packages/bar/node_modules/some-package/some-subfolder/package.json'

findPackageJSON(