Node.js v21.7.2 ドキュメント

有効化#

Node.js には、CommonJS モジュールと ECMAScript モジュールの 2 つのモジュールシステムがあります。

デフォルトでは、Node.js は次のようなものを CommonJS モジュールとして扱います。

• .cjs 拡張子を持つファイル。

• 最も近い親 package.json ファイルに、値が "commonjs" のトップレベルフィールド "type" が含まれている場合の、.js 拡張子を持つファイル。

• 最も近い親 package.json ファイルにトップレベルフィールド "type" が含まれていない場合、または親フォルダに package.json がない場合の、.js 拡張子を持つファイル、または拡張子のないファイル。ただし、ES モジュールとして評価されない限りエラーが発生する構文がファイルに含まれている場合を除きます。パッケージ作成者は、すべてのソースが CommonJS であるパッケージでも、"type" フィールドを含める必要があります。パッケージの type を明示的に示すことで、ビルドツールやローダーがパッケージ内のファイルをどのように解釈する必要があるかを判断することが容易になります。

• .mjs、.cjs、.json、.node、または .js ではない拡張子を持つファイル (最も近い親 package.json ファイルに値が "module" のトップレベルフィールド "type" が含まれている場合、これらのファイルは require() 経由で含まれている場合にのみ CommonJS モジュールとして認識されます。プログラムのコマンドラインのエントリポイントとして使用される場合は認識されません)。

詳細については、「モジュールシステムの決定」を参照してください。

require() を呼び出すと、常に CommonJS モジュールローダーが使用されます。import() を呼び出すと、常に ECMAScript モジュールローダーが使用されます。

メインモジュールへのアクセス#

ファイルが Node.js から直接実行されると、require.main はその module に設定されます。これは、require.main === module をテストすることで、ファイルが直接実行されたかどうかを判断できることを意味します。

ファイル foo.js の場合、node foo.js で実行された場合はこれが true になりますが、require('./foo') で実行された場合は false になります。

エントリポイントが CommonJS モジュールでない場合、require.main は undefined であり、メインモジュールに到達できません。

パッケージマネージャーのヒント#

Node.js require() 関数のセマンティクスは、適切なディレクトリ構造をサポートするのに十分な汎用性を持つように設計されています。dpkg、rpm、npm などのパッケージマネージャープログラムは、Node.js モジュールからネイティブパッケージを修正なしで構築できることを期待しています。

以下に、機能する可能性のある推奨されるディレクトリ構造を示します。

/usr/lib/node/<some-package>/<some-version> に特定のバージョンのパッケージの内容を保持したいとします。

パッケージは相互に依存することができます。パッケージ foo をインストールするには、特定のバージョンのパッケージ bar をインストールする必要がある場合があります。bar パッケージ自体にも依存関係があり、場合によっては、これらが競合したり、循環依存関係を形成したりすることさえあります。

Node.js はロードするモジュールの realpath (つまり、シンボリックリンクを解決します) を検索し、node_modules フォルダで依存関係を検索するため、この状況は次のアーキテクチャで解決できます。

• /usr/lib/node/foo/1.2.3/: foo パッケージの内容、バージョン 1.2.3。
• /usr/lib/node/bar/4.3.2/: foo が依存する bar パッケージの内容。
• /usr/lib/node/foo/1.2.3/node_modules/bar: /usr/lib/node/bar/4.3.2/ へのシンボリックリンク。
• /usr/lib/node/bar/4.3.2/node_modules/*: bar が依存するパッケージへのシンボリックリンク。

したがって、サイクルが発生した場合、または依存関係の競合がある場合でも、すべてのモジュールは使用できる依存関係のバージョンを取得できます。

foo パッケージ内のコードが require('bar') を実行すると、/usr/lib/node/foo/1.2.3/node_modules/bar にシンボリックリンクされているバージョンが取得されます。次に、bar パッケージ内のコードが require('quux') を呼び出すと、/usr/lib/node/bar/4.3.2/node_modules/quux にシンボリックリンクされているバージョンが取得されます。

さらに、モジュール検索プロセスをさらに最適化するために、パッケージを /usr/lib/node に直接配置するのではなく、/usr/lib/node_modules/<name>/<version> に配置できます。そうすると、Node.js は /usr/node_modules や /node_modules で欠落している依存関係を探す手間が省けます。

Node.js REPL でモジュールを利用できるようにするには、/usr/lib/node_modules フォルダを $NODE_PATH 環境変数に追加することも便利です。node_modules フォルダを使用したモジュール検索はすべて相対的であり、require() を呼び出すファイルの実際のパスに基づいているため、パッケージ自体はどこにでも配置できます。

.mjs 拡張子#

require() は同期的な性質のため、これを使用して ECMAScript モジュールファイルをロードすることはできません。これを行おうとすると、ERR_REQUIRE_ESM エラーがスローされます。代わりに、import() を使用してください。

.mjs 拡張子は ECMAScript モジュール用に予約されており、require() を介してロードすることはできません。どのファイルが ECMAScript モジュールとして解析されるかについての詳細は、「モジュールシステムの決定」のセクションを参照してください。

すべてをまとめる#

require() が呼び出されたときにロードされる正確なファイル名を取得するには、require.resolve() 関数を使用します。

上記のすべてをまとめると、require() が行うことの疑似コードでの高レベルのアルゴリズムを次に示します。

require(X) from module at path Y
1. If X is a core module,
   a. return the core module
   b. STOP
2. If X begins with '/'
   a. set Y to be the file system root
3. If X begins with './' or '/' or '../'
   a. LOAD_AS_FILE(Y + X)
   b. LOAD_AS_DIRECTORY(Y + X)
   c. THROW "not found"
4. If X begins with '#'
   a. LOAD_PACKAGE_IMPORTS(X, dirname(Y))
5. LOAD_PACKAGE_SELF(X, dirname(Y))
6. LOAD_NODE_MODULES(X, dirname(Y))
7. THROW "not found"

LOAD_AS_FILE(X)
1. If X is a file, load X as its file extension format. STOP
2. If X.js is a file, load X.js as JavaScript text. STOP
3. If X.json is a file, parse X.json to a JavaScript Object. STOP
4. If X.node is a file, load X.node as binary addon. STOP

LOAD_INDEX(X)
1. If X/index.js is a file, load X/index.js as JavaScript text. STOP
2. If X/index.json is a file, parse X/index.json to a JavaScript object. STOP
3. If X/index.node is a file, load X/index.node as binary addon. STOP

LOAD_AS_DIRECTORY(X)
1. If X/package.json is a file,
   a. Parse X/package.json, and look for "main" field.
   b. If "main" is a falsy value, GOTO 2.
   c. let M = X + (json main field)
   d. LOAD_AS_FILE(M)
   e. LOAD_INDEX(M)
   f. LOAD_INDEX(X) DEPRECATED
   g. THROW "not found"
2. LOAD_INDEX(X)

LOAD_NODE_MODULES(X, START)
1. let DIRS = NODE_MODULES_PATHS(START)
2. for each DIR in DIRS:
   a. LOAD_PACKAGE_EXPORTS(X, DIR)
   b. LOAD_AS_FILE(DIR/X)
   c. LOAD_AS_DIRECTORY(DIR/X)

NODE_MODULES_PATHS(START)
1. let PARTS = path split(START)
2. let I = count of PARTS - 1
3. let DIRS = []
4. while I >= 0,
   a. if PARTS[I] = "node_modules" CONTINUE
   b. DIR = path join(PARTS[0 .. I] + "node_modules")
   c. DIRS = DIR + DIRS
   d. let I = I - 1
5. return DIRS + GLOBAL_FOLDERS

LOAD_PACKAGE_IMPORTS(X, DIR)
1. Find the closest package scope SCOPE to DIR.
2. If no scope was found, return.
3. If the SCOPE/package.json "imports" is null or undefined, return.
4. let MATCH = PACKAGE_IMPORTS_RESOLVE(X, pathToFileURL(SCOPE),
  ["node", "require"]) defined in the ESM resolver.
5. RESOLVE_ESM_MATCH(MATCH).

LOAD_PACKAGE_EXPORTS(X, DIR)
1. Try to interpret X as a combination of NAME and SUBPATH where the name
   may have a @scope/ prefix and the subpath begins with a slash (`/`).
2. If X does not match this pattern or DIR/NAME/package.json is not a file,
   return.
3. Parse DIR/NAME/package.json, and look for "exports" field.
4. If "exports" is null or undefined, return.
5. let MATCH = PACKAGE_EXPORTS_RESOLVE(pathToFileURL(DIR/NAME), "." + SUBPATH,
   `package.json` "exports", ["node", "require"]) defined in the ESM resolver.
6. RESOLVE_ESM_MATCH(MATCH)

LOAD_PACKAGE_SELF(X, DIR)
1. Find the closest package scope SCOPE to DIR.
2. If no scope was found, return.
3. If the SCOPE/package.json "exports" is null or undefined, return.
4. If the SCOPE/package.json "name" is not the first segment of X, return.
5. let MATCH = PACKAGE_EXPORTS_RESOLVE(pathToFileURL(SCOPE),
   "." + X.slice("name".length), `package.json` "exports", ["node", "require"])
   defined in the ESM resolver.
6. RESOLVE_ESM_MATCH(MATCH)

RESOLVE_ESM_MATCH(MATCH)
1. let RESOLVED_PATH = fileURLToPath(MATCH)
2. If the file at RESOLVED_PATH exists, load RESOLVED_PATH as its extension
   format. STOP
3. THROW "not found"

キャッシュ#

モジュールは、最初にロードされた後でキャッシュされます。これは (特に) require('foo') を呼び出すたびに、同じファイルに解決される場合は、まったく同じオブジェクトが返されることを意味します。

require.cache が変更されない限り、require('foo') を複数回呼び出しても、モジュールコードが複数回実行されることはありません。これは重要な機能です。これにより、「部分的に完了した」オブジェクトを返すことができるため、サイクルが発生する可能性のある場合でも、推移的な依存関係をロードできます。

モジュールコードを複数回実行するには、関数をエクスポートし、その関数を呼び出します。

モジュールキャッシュの注意点#

モジュールは、解決されたファイル名に基づいてキャッシュされます。モジュールは、呼び出し元のモジュールの場所 (node_modules フォルダからのロード) に基づいて異なるファイル名に解決される可能性があるため、require('foo') が常にまったく同じオブジェクトを返すとは限りません。これは、異なるファイルに解決される場合です。

さらに、大文字小文字を区別しないファイルシステムやオペレーティングシステムでは、解決されたファイル名が異なると同じファイルを指すことがありますが、キャッシュはそれらを異なるモジュールとして扱い、ファイルを複数回リロードします。たとえば、require('./foo') と require('./FOO') は、./foo と ./FOO が同じファイルであるかどうかに関係なく、2つの異なるオブジェクトを返します。

コアモジュール#

Node.js には、バイナリにコンパイルされたいくつかのモジュールがあります。これらのモジュールについては、このドキュメントの他の箇所で詳しく説明します。

コアモジュールは、Node.js のソース内で定義されており、lib/ フォルダにあります。

コアモジュールは、node: プレフィックスを使用して識別できます。この場合、require キャッシュをバイパスします。たとえば、require('node:http') は、その名前で require.cache エントリがある場合でも、常に組み込みの HTTP モジュールを返します。

一部のコアモジュールは、識別子が require() に渡されると常に優先的にロードされます。たとえば、require('http') は、その名前のファイルがある場合でも、常に組み込みの HTTP モジュールを返します。node: プレフィックスを使用せずにロードできるコアモジュールのリストは、module.builtinModules として公開されています。

循環#

require() の呼び出しが循環している場合、モジュールが返されるときに実行が完了していない可能性があります。

この状況を考えてみましょう

a.js:

console.log('a starting');
exports.done = false;
const b = require('./b.js');
console.log('in a, b.done = %j', b.done);
exports.done = true;
console.log('a done'); copy

b.js:

console.log('b starting');
exports.done = false;
const a = require('./a.js');
console.log('in b, a.done = %j', a.done);
exports.done = true;
console.log('b done'); copy

main.js:

console.log('main starting');
const a = require('./a.js');
const b = require('./b.js');
console.log('in main, a.done = %j, b.done = %j', a.done, b.done); copy

main.js が a.js をロードすると、次に a.js が b.js をロードします。その時点で、b.js が a.js をロードしようとします。無限ループを防ぐために、a.js のエクスポートオブジェクトの未完了コピーが b.js モジュールに返されます。次に、b.js のロードが完了し、その exports オブジェクトが a.js モジュールに提供されます。

main.js が両方のモジュールをロードするまでに、両方とも完了しています。したがって、このプログラムの出力は次のようになります。

$ node main.js
main starting
a starting
b starting
in b, a.done = false
b done
in a, b.done = true
a done
in main, a.done = true, b.done = true copy

アプリケーション内で循環モジュール依存関係が正しく機能するようにするには、慎重な計画が必要です。

ファイルモジュール#

正確なファイル名が見つからない場合、Node.js は、拡張子 .js、.json、最後に .node を追加して、必要なファイル名のロードを試みます。異なる拡張子（たとえば .cjs）を持つファイルをロードする場合は、そのファイル拡張子を含む完全な名前を require() に渡す必要があります（たとえば require('./file.cjs')）。

.json ファイルは JSON テキストファイルとして解析され、.node ファイルは process.dlopen() でロードされるコンパイル済みアドオンモジュールとして解釈されます。他の拡張子（または拡張子がまったくない）を使用するファイルは、JavaScript テキストファイルとして解析されます。使用される解析目標を理解するには、モジュールシステムの決定セクションを参照してください。

'/' で始まる必須モジュールは、ファイルへの絶対パスです。たとえば、require('/home/marco/foo.js') は /home/marco/foo.js にあるファイルをロードします。

'./' で始まる必須モジュールは、require() を呼び出すファイルに対して相対的です。つまり、require('./circle') が見つけるためには、circle.js は foo.js と同じディレクトリにある必要があります。

ファイルを示す先頭の '/'、'./'、または '../' がない場合、モジュールはコアモジュールであるか、node_modules フォルダからロードされる必要があります。

指定されたパスが存在しない場合、require() は MODULE_NOT_FOUND エラーをスローします。

モジュールとしてのフォルダ#

フォルダを引数として require() に渡すことができる方法は 3 つあります。

1 つ目は、フォルダのルートに package.json ファイルを作成し、main モジュールを指定することです。package.json ファイルの例は次のようになります。

{ "name" : "some-library",
  "main" : "./lib/some-library.js" } copy

これが ./some-library のフォルダにある場合、require('./some-library') は ./some-library/lib/some-library.js のロードを試みます。

ディレクトリに package.json ファイルが存在しない場合、または "main" エントリが見つからないか解決できない場合、Node.js はそのディレクトリから index.js または index.node ファイルをロードしようとします。たとえば、前の例に package.json ファイルがない場合、require('./some-library') は次のロードを試みます。

• ./some-library/index.js
• ./some-library/index.node

これらの試行が失敗した場合、Node.js はモジュール全体がデフォルトエラーで不足していると報告します。

Error: Cannot find module 'some-library' copy

上記の 3 つのケースすべてにおいて、import('./some-library') を呼び出すと、ERR_UNSUPPORTED_DIR_IMPORT エラーが発生します。パッケージの サブパスエクスポート または サブパスインポート を使用すると、モジュールとしてのフォルダと同じ包含組織の利点が得られ、require と import の両方で機能します。

node_modules フォルダからのロード#

require() に渡されたモジュール識別子が コア モジュールではなく、'/'、'../'、または './' で始まらない場合、Node.js は現在のモジュールのディレクトリから開始し、/node_modules を追加して、その場所からモジュールをロードしようとします。Node.js は、既に node_modules で終わるパスに node_modules を追加しません。

そこに見つからない場合、親ディレクトリに移動し、ファイルシステムのルートに到達するまで続行します。

たとえば、'/home/ry/projects/foo.js' にあるファイルが require('bar.js') を呼び出した場合、Node.js は次の場所をこの順序で検索します。

• /home/ry/projects/node_modules/bar.js
• /home/ry/node_modules/bar.js
• /home/node_modules/bar.js
• /node_modules/bar.js

これにより、プログラムは依存関係をローカライズできるため、競合することはありません。

モジュール名にパスサフィックスを含めることで、モジュールとともに配布される特定のファイルまたはサブモジュールを要求できます。たとえば、require('example-module/path/to/file') は、example-module が配置されている場所を基準にして path/to/file を解決します。サフィックス付きパスは、同じモジュール解決セマンティクスに従います。

グローバルフォルダからのロード#

NODE_PATH 環境変数がコロン区切りの絶対パスのリストに設定されている場合、Node.js は、他の場所で見つからない場合、それらのパスでモジュールを検索します。

Windows では、NODE_PATH はコロンではなくセミコロン (;) で区切られます。

NODE_PATH は、現在の モジュール解決 アルゴリズムが定義される前に、さまざまなパスからモジュールをロードすることをサポートするために最初に作成されました。

NODE_PATH はまだサポートされていますが、Node.js エコシステムが依存モジュールを配置するための慣例に落ち着いたため、現在では必要性が低くなっています。NODE_PATH に依存するデプロイメントでは、NODE_PATH を設定する必要があることを認識していない場合、驚くべき動作を示す場合があります。モジュールの依存関係が変更されると、NODE_PATH が検索されるときに、異なるバージョン（または異なるモジュールでさえ）がロードされることがあります。

さらに、Node.js は次の GLOBAL_FOLDERS のリストも検索します。

• 1: $HOME/.node_modules
• 2: $HOME/.node_libraries
• 3: $PREFIX/lib/node

ここで、$HOME はユーザーのホームディレクトリであり、$PREFIX は Node.js 構成済みの node_prefix です。

これらは主に歴史的な理由によるものです。

依存関係はローカルの node_modules フォルダに配置することを強くお勧めします。これらはより速く、より確実にロードされます。

モジュールラッパー#

モジュールのコードが実行される前に、Node.js は次のよう関数ラッパーでコードをラップします。

(function(exports, require, module, __filename, __dirname) {
// Module code actually lives in here
}); copy

このようにすることで、Node.js はいくつかのことを実現します。

• トップレベル変数 (var、const、または let で定義) は、グローバルオブジェクトではなく、モジュールにスコープされます。
• モジュールに固有の実際にはグローバルに見えるいくつかの変数を提供します。例:
  • 実装者がモジュールから値をエクスポートするために使用できる module および exports オブジェクト。
  • モジュールの絶対ファイル名とディレクトリパスを含む便利な変数 __filename および __dirname。

モジュールスコープ#

__dirname#

• <文字列>

現在のモジュールのディレクトリ名。これは、__filename の path.dirname() と同じです。

例: /Users/mjr から node example.js を実行する

console.log(__dirname);
// Prints: /Users/mjr
console.log(path.dirname(__filename));
// Prints: /Users/mjr copy

__filename#

• <文字列>

現在のモジュールのファイル名。これは、シンボリックリンクが解決された現在のモジュールファイルの絶対パスです。

メインプログラムの場合、これはコマンドラインで使用されるファイル名と同じであるとは限りません。

現在のモジュールのディレクトリ名については、__dirname を参照してください。

例

/Users/mjr から node example.js を実行する

console.log(__filename);
// Prints: /Users/mjr/example.js
console.log(__dirname);
// Prints: /Users/mjr copy

2つのモジュール a と b があり、b が a の依存関係であり、ディレクトリ構造が

• /Users/mjr/app/a.js
• /Users/mjr/app/node_modules/b/b.js

b.js 内の __filename の参照は /Users/mjr/app/node_modules/b/b.js を返し、a.js 内の __filename の参照は /Users/mjr/app/a.js を返します。

exports#

• <オブジェクト>

入力するのに短い module.exports への参照。exports と module.exports のどちらを使用するかについての詳細は、exports ショートカットに関するセクションを参照してください。

module#

• <モジュール>

現在のモジュールへの参照。module オブジェクトに関するセクションを参照してください。特に、module.exports は、モジュールがエクスポートし、require() を通じて利用可能にするものを定義するために使用されます。

require(id)#

• id <string> モジュール名またはパス
• 戻り値: <any> エクスポートされたモジュールコンテンツ

モジュール、JSON、およびローカルファイルのインポートに使用されます。モジュールはnode_modulesからインポートできます。ローカルモジュールとJSONファイルは、__dirname (定義されている場合) によって指定されたディレクトリまたは現在の作業ディレクトリを基準として解決される相対パス (例: ./、./foo、./bar/baz、../foo) を使用してインポートできます。POSIXスタイルの相対パスはOSに依存しない方法で解決されます。つまり、上記の例はUnixシステムと同じようにWindowsでも機能します。

// Importing a local module with a path relative to the `__dirname` or current
// working directory. (On Windows, this would resolve to .\path\myLocalModule.)
const myLocalModule = require('./path/myLocalModule');

// Importing a JSON file:
const jsonData = require('./path/filename.json');

// Importing a module from node_modules or Node.js built-in module:
const crypto = require('node:crypto'); copy

require.cache#

• <オブジェクト>

モジュールは、requireされるとこのオブジェクトにキャッシュされます。このオブジェクトからキー値を削除すると、次回のrequireでモジュールがリロードされます。これは、ネイティブアドオンには適用されません。リロードするとエラーが発生します。

エントリの追加や置換も可能です。このキャッシュは組み込みモジュールよりも前にチェックされ、組み込みモジュールに一致する名前がキャッシュに追加されると、node:プレフィックス付きのrequire呼び出しのみが組み込みモジュールを受け取ります。使用には注意してください！

const assert = require('node:assert');
const realFs = require('node:fs');

const fakeFs = {};
require.cache.fs = { exports: fakeFs };

assert.strictEqual(require('fs'), fakeFs);
assert.strictEqual(require('node:fs'), realFs); copy

require.extensions#

• <オブジェクト>

特定のファイル拡張子を処理する方法をrequireに指示します。

拡張子.sjsのファイルを.jsとして処理します

require.extensions['.sjs'] = require.extensions['.js']; copy

非推奨。 過去には、このリストは、オンデマンドでコンパイルすることにより、非JavaScriptモジュールをNode.jsにロードするために使用されていました。ただし、実際には、他のNode.jsプログラムを介してモジュールをロードしたり、事前にJavaScriptにコンパイルしたりするなど、より良い方法が数多く存在します。

require.extensionsの使用は避けてください。使用すると、微妙なバグが発生する可能性があり、登録された拡張機能が増えるほど拡張機能の解決が遅くなります。

require.main#

• <module> | <undefined>

Node.jsプロセスが起動したときにロードされたエントリスクリプトを表すModuleオブジェクト、またはプログラムのエントリポイントがCommonJSモジュールでない場合はundefinedです。「メインモジュールへのアクセス」を参照してください。

entry.jsスクリプト内

console.log(require.main); copy

node entry.js copy

Module {
  id: '.',
  path: '/absolute/path/to',
  exports: {},
  filename: '/absolute/path/to/entry.js',
  loaded: false,
  children: [],
  paths:
   [ '/absolute/path/to/node_modules',
     '/absolute/path/node_modules',
     '/absolute/node_modules',
     '/node_modules' ] } copy

require.resolve(request[, options])#

• request <string> 解決するモジュールパス。
• options <Object>
  • paths <string[]> モジュールの場所を解決するためのパス。存在する場合、これらのパスは、$HOME/.node_modulesなどのGLOBAL_FOLDERSを除き、デフォルトの解決パスの代わりに使用されます。これらのパスはそれぞれ、モジュール解決アルゴリズムの開始点として使用されます。つまり、node_modules階層がこの場所からチェックされます。
• 戻り値: <string>

内部のrequire()機構を使用してモジュールの場所を検索しますが、モジュールをロードするのではなく、解決されたファイル名を返すだけです。

モジュールが見つからない場合は、MODULE_NOT_FOUNDエラーがスローされます。

require.resolve.paths(request)#

• request <string> 検索パスを取得するモジュールパス。
• 戻り値: <string[]> | <null>

requestの解決中に検索されたパスを含む配列、またはrequest文字列がhttpやfsなどのコアモジュールを参照する場合はnullを返します。

moduleオブジェクト#

• <オブジェクト>

各モジュールでは、moduleという自由変数は、現在のモジュールを表すオブジェクトへの参照です。便宜上、module.exportsはexportsモジュールグローバル変数からもアクセスできます。moduleは実際にはグローバル変数ではなく、各モジュールに対してローカルです。

module.children#

• <module[]>

このモジュールによって最初にrequireされたモジュールオブジェクト。

module.exports#

• <オブジェクト>

module.exportsオブジェクトは、Moduleシステムによって作成されます。場合によっては、これが適切でないことがあります。多くの人が自分のモジュールを何らかのクラスのインスタンスにしたいと考えています。これを行うには、目的のエクスポートオブジェクトをmodule.exportsに割り当てます。目的のオブジェクトをexportsに割り当てると、ローカルのexports変数が再バインドされるだけです。これはおそらく意図したものではありません。

たとえば、a.jsというモジュールを作成しているとします。

const EventEmitter = require('node:events');

module.exports = new EventEmitter();

// Do some work, and after some time emit
// the 'ready' event from the module itself.
setTimeout(() => {
  module.exports.emit('ready');
}, 1000); copy

次に、別のファイルで次のようにすることができます。

const a = require('./a');
a.on('ready', () => {
  console.log('module "a" is ready');
}); copy

module.exportsへの割り当ては、すぐに行う必要があります。コールバック内では行うことができません。これは機能しません。

x.js:

setTimeout(() => {
  module.exports = { a: 'hello' };
}, 0); copy

y.js:

const x = require('./x');
console.log(x.a); copy

exportsショートカット#

exports変数は、モジュールのファイルレベルスコープ内で使用可能であり、モジュールが評価される前にmodule.exportsの値が割り当てられます。

これにより、module.exports.f = ...をexports.f = ...としてより簡潔に記述できるショートカットが可能になります。ただし、任意の変数と同様に、新しい値がexportsに割り当てられると、それはmodule.exportsにバインドされなくなることに注意してください。

module.exports.hello = true; // Exported from require of module
exports = { hello: false };  // Not exported, only available in the module copy

module.exportsプロパティが完全に新しいオブジェクトに置き換えられる場合は、exportsも再割り当てするのが一般的です。

module.exports = exports = function Constructor() {
  // ... etc.
}; copy

動作を説明するために、require()の架空の実装を想像してみてください。これは、require()が実際に行うことに非常に似ています。

function require(/* ... */) {
  const module = { exports: {} };
  ((module, exports) => {
    // Module code here. In this example, define a function.
    function someFunc() {}
    exports = someFunc;
    // At this point, exports is no longer a shortcut to module.exports, and
    // this module will still export an empty default object.
    module.exports = someFunc;
    // At this point, the module will now export someFunc, instead of the
    // default object.
  })(module, module.exports);
  return module.exports;
} copy

module.filename#

• <文字列>

モジュールの完全に解決されたファイル名。

module.id#

• <文字列>

モジュールの識別子。通常、これは完全に解決されたファイル名です。

module.isPreloading#

• 型: <boolean> モジュールがNode.jsのプリロードフェーズ中に実行されている場合はtrue。

module.loaded#

• <boolean>

モジュールの読み込みが完了しているか、読み込み中であるか。

module.parent#

• <module> | <null> | <undefined>

このモジュールを最初にrequireしたモジュール。現在のモジュールが現在のプロセスのエントリポイントである場合はnull。モジュールがCommonJSモジュールではないもの（例：REPLまたはimport）によってロードされた場合はundefined。

module.path#

• <文字列>

モジュールのディレクトリ名。通常、これはmodule.idのpath.dirname()と同じです。

module.paths#

• <string[]>

モジュールの検索パス。

module.require(id)#

• id <string>
• 戻り値: <any> エクスポートされたモジュールコンテンツ

module.require()メソッドは、元のモジュールからrequire()が呼び出されたかのようにモジュールをロードする方法を提供します。

これを行うには、moduleオブジェクトへの参照を取得する必要があります。require()はmodule.exportsを返し、moduleは通常、特定のモジュールのコード内でのみ使用できるため、使用するには明示的にエクスポートする必要があります。

Moduleオブジェクト#

このセクションは、モジュール: moduleコアモジュールに移動しました。

• module.builtinModules
• module.createRequire(filename)
• module.syncBuiltinESMExports()

ソースマップv3のサポート#

このセクションは、モジュール: moduleコアモジュールに移動しました。

• module.findSourceMap(path)
• クラス: module.SourceMap
  • new SourceMap(payload)
  • sourceMap.payload
  • sourceMap.findEntry(lineNumber, columnNumber)