Включение

Node.js имеет две системы модулей: модули CommonJS и модули ECMAScript.

По умолчанию Node.js будет считать модулями CommonJS следующее:

• Файлы с расширением .cjs;

• Файлы с расширением .js, если ближайший родительский файл package.json содержит поле верхнего уровня "type" со значением "commonjs".

• Файлы с расширением .js или без расширения, если ближайший родительский файл package.json не содержит поле верхнего уровня "type" или ни в одной из родительских папок нет файла package.json; за исключением случаев, когда файл содержит синтаксис, вызывающий ошибку, если он не обрабатывается как модуль ES. Авторам пакетов следует включать поле "type" даже в пакеты, где все исходные файлы относятся к CommonJS. Явное указание type пакета упростит инструментам сборки и загрузчикам определение того, как следует интерпретировать файлы в пакете.

• Файлы с расширением, отличным от .mjs, .cjs, .json, .node или .js (если ближайший родительский файл package.json содержит поле верхнего уровня "type" со значением "module", эти файлы будут распознаваться как модули CommonJS только при подключении через require(), а не при использовании в качестве точки входа программы из командной строки).

См. раздел Определение системы модулей для более подробной информации.

Вызов require() всегда использует загрузчик модулей CommonJS. Вызов import() всегда использует загрузчик модулей ECMAScript.

Доступ к главному модулю

Когда файл запускается напрямую из Node.js, свойству require.main присваивается его module. Это означает, что можно определить, был ли файл запущен напрямую, проверив require.main === module.

Для файла foo.js это выражение вернёт true при запуске через node foo.js, но false при запуске с помощью require('./foo').

Когда точка входа не является модулем 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/: Содержимое пакета bar, от которого зависит foo.
• /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(), сами пакеты могут находиться где угодно.

Загрузка модулей ECMAScript с помощью require()

Расширение .mjs зарезервировано для модулей ECMAScript. См. раздел Определение системы модулей для получения дополнительной информации о том, какие файлы анализируются как модули ECMAScript.

require() поддерживает загрузку только тех модулей ECMAScript, которые соответствуют следующим требованиям:

• Модуль полностью синхронный (не содержит await на верхнем уровне); и
• Выполняется одно из следующих условий:
  1. Файл имеет расширение .mjs.
  2. Файл имеет расширение .js, а ближайший package.json содержит "type": "module"
  3. Файл имеет расширение .js, ближайший package.json не содержит "type": "commonjs", и модуль содержит синтаксис модулей ES.

Если загружаемый модуль ES соответствует этим требованиям, require() может загрузить его и вернуть объект пространства имен модуля. В этом случае он похож на динамический import(), но выполняется синхронно и возвращает объект пространства имен напрямую.

При наличии следующих модулей ES:

// distance.mjs
export function distance(a, b) { return Math.sqrt((b.x - a.x) ** 2 + (b.y - a.y) ** 2); } copy

// point.mjs
export default class Point {
  constructor(x, y) { this.x = x; this.y = y; }
} copy

Модуль CommonJS может загружать их с помощью require():

const distance = require('./distance.mjs');
console.log(distance);
// [Module: null prototype] {
//   distance: [Function: distance]
// }

const point = require('./point.mjs');
console.log(point);
// [Module: null prototype] {
//   default: [class Point],
//   __esModule: true,
// } copy

Для обеспечения совместимости с существующими инструментами, преобразующими модули ES в CommonJS, которые затем могут загружать реальные модули ES через require(), возвращаемое пространство имен будет содержать свойство __esModule: true, если оно имеет экспорт default, чтобы сгенерированный инструментами вызывающий код мог распознавать экспорты по умолчанию в реальных модулях ES. Если пространство имен уже определяет __esModule, оно не будет добавлено. Это свойство является экспериментальным и может измениться в будущем. Его следует использовать только инструментам, преобразующим модули ES в модули CommonJS в соответствии с существующими соглашениями экосистемы. Коду, написанному непосредственно на CommonJS, следует избегать зависимости от него.

Когда модуль ES содержит как именованные экспорты, так и экспорт по умолчанию, результат, возвращаемый require(), представляет собой объект пространства имен модуля, который помещает экспорт по умолчанию в свойство .default аналогично результатам, возвращаемым import(). Чтобы настроить, что именно должно возвращаться напрямую через require(esm), модуль ES может экспортировать желаемое значение, используя строковое имя "module.exports".

// point.mjs
export default class Point {
  constructor(x, y) { this.x = x; this.y = y; }
}

// `distance` is lost to CommonJS consumers of this module, unless it's
// added to `Point` as a static property.
export function distance(a, b) { return Math.sqrt((b.x - a.x) ** 2 + (b.y - a.y) ** 2); }
export { Point as 'module.exports' } copy

const Point = require('./point.mjs');
console.log(Point); // [class Point]

// Named exports are lost when 'module.exports' is used
const { distance } = require('./point.mjs');
console.log(distance); // undefined copy

Обратите внимание, что в приведенном выше примере при использовании имени экспорта module.exports именованные экспорты будут недоступны для потребителей CommonJS. Чтобы позволить потребителям CommonJS продолжать доступ к именованным экспортам, модуль может гарантировать, что экспорт по умолчанию является объектом с прикрепленными к нему в виде свойств именованными экспортами. Например, в случае выше distance можно прикрепить к экспорту по умолчанию — классу Point — в качестве статического метода.

export function distance(a, b) { return Math.sqrt((b.x - a.x) ** 2 + (b.y - a.y) ** 2); }

export default class Point {
  constructor(x, y) { this.x = x; this.y = y; }
  static distance = distance;
}

export { Point as 'module.exports' } copy

const Point = require('./point.mjs');
console.log(Point); // [class Point]

const { distance } = require('./point.mjs');
console.log(distance); // [Function: distance] copy

Если загружаемый с помощью require() модуль содержит await верхнего уровня или граф модулей, который он import, содержит await верхнего уровня, будет выброшена ошибка ERR_REQUIRE_ASYNC_MODULE. В этом случае пользователям следует загружать асинхронный модуль с помощью import().

Если включен флаг --experimental-print-required-tla, вместо выброса ERR_REQUIRE_ASYNC_MODULE перед вычислением Node.js выполнит модуль, попытается найти вызовы await верхнего уровня и выведет их расположение, чтобы помочь пользователям исправить их.

Поддержка загрузки модулей ES с помощью require() в настоящее время является экспериментальной и может быть отключена с помощью --no-experimental-require-module. Чтобы вывести информацию о том, где используется эта функция, используйте --trace-require-module.

Эту функцию можно обнаружить, проверив, имеет ли process.features.require_module значение true.

Всё вместе

Чтобы получить точное имя файла, который будет загружен при вызове 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 the file system root
3. If X is equal to '.', or X begins with './', '/' 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"

MAYBE_DETECT_AND_LOAD(X)
1. If X parses as a CommonJS module, load X as a CommonJS module. STOP.
2. Else, if the source code of X can be parsed as ECMAScript module using
  <a href="esm.md#resolver-algorithm-specification">DETECT_MODULE_SYNTAX defined in
  the ESM resolver</a>,
  a. Load X as an ECMAScript module. STOP.
3. THROW the SyntaxError from attempting to parse X as CommonJS in 1. STOP.

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,
    a. Find the closest package scope SCOPE to X.
    b. If no scope was found
      1. MAYBE_DETECT_AND_LOAD(X.js)
    c. If the SCOPE/package.json contains "type" field,
      1. If the "type" field is "module", load X.js as an ECMAScript module. STOP.
      2. If the "type" field is "commonjs", load X.js as a CommonJS module. STOP.
    d. MAYBE_DETECT_AND_LOAD(X.js)
3. If X.json is a file, load 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
    a. Find the closest package scope SCOPE to X.
    b. If no scope was found, load X/index.js as a CommonJS module. STOP.
    c. If the SCOPE/package.json contains "type" field,
      1. If the "type" field is "module", load X/index.js as an ECMAScript module. STOP.
      2. Else, load X/index.js as a CommonJS module. 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", GOTO d.
   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. If `--experimental-require-module` is enabled
  a. let CONDITIONS = ["node", "require", "module-sync"]
  b. Else, let CONDITIONS = ["node", "require"]
5. let MATCH = PACKAGE_IMPORTS_RESOLVE(X, pathToFileURL(SCOPE),
  CONDITIONS) <a href="esm.md#resolver-algorithm-specification">defined in the ESM resolver</a>.
6. 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. If `--experimental-require-module` is enabled
  a. let CONDITIONS = ["node", "require", "module-sync"]
  b. Else, let CONDITIONS = ["node", "require"]
6. let MATCH = PACKAGE_EXPORTS_RESOLVE(pathToFileURL(DIR/NAME), "." + SUBPATH,
   `package.json` "exports", CONDITIONS) <a href="esm.md#resolver-algorithm-specification">defined in the ESM resolver</a>.
7. 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"])
   <a href="esm.md#resolver-algorithm-specification">defined in the ESM resolver</a>.
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" copy

Кэширование

Модули кэшируются после первой загрузки. Это означает (среди прочего), что каждый вызов require('foo') вернет в точности один и тот же объект, если он разрешается в один и тот же файл.

При условии, что require.cache не изменяется, множественные вызовы require('foo') не приведут к многократному выполнению кода модуля. Это важная особенность. Благодаря ей могут возвращаться «частично готовые» объекты, что позволяет загружать транзитивные зависимости, даже если они образуют циклы.

Чтобы модуль выполнял код несколько раз, экспортируйте функцию и вызовите её.

Встроенные модули

В Node.js есть несколько модулей, скомпилированных в бинарный файл. Эти модули более подробно описаны в других разделах этой документации.

Встроенные модули определены в исходном коде Node.js и расположены в папке lib/.

Встроенные модули можно идентифицировать с помощью префикса node:, и в этом случае запрос обходит кэш require. Например, require('node:http') всегда будет возвращать встроенный модуль HTTP, даже если существует запись require.cache с таким именем.

Некоторые встроенные модули всегда загружаются в приоритетном порядке, если их идентификатор передан в 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(). То есть circle.js должен находиться в том же каталоге, что и foo.js, чтобы require('./circle') мог найти его.

Без ведущего '/', './' или '../' для указания файла модуль должен быть либо встроенным модулем, либо загружаться из папки node_modules.

Если указанный путь не существует, require() выбросит ошибку MODULE_NOT_FOUND.

Папки как модули

Существует три способа передачи папки в require() в качестве аргумента.

Первый способ — создать файл 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

Во всех трех описанных выше случаях вызов 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') разрешит path/to/file относительно расположения example-module. Путь с суффиксом следует той же семантике разрешения модулей.

Загрузка из глобальных папок

Если переменная окружения 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, содержащие абсолютное имя файла модуля и путь к каталогу.

Область видимости модуля

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

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

// 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

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['.sjs'] = require.extensions['.js']; copy

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

Объект module

• Тип: <Object>

В каждом модуле свободная переменная module является ссылкой на объект, представляющий текущий модуль. Для удобства module.exports также доступен через глобальную переменную модуля exports. На самом деле module не является глобальной переменной, а скорее локальной для каждого модуля.

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

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

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

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

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

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

Этот раздел был перемещен в Модули: встроенный модуль module.

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

Поддержка Source map v3

Этот раздел был перемещен в Модули: встроенный модуль module.

• module.findSourceMap(path)
• Класс: module.SourceMap
  • new SourceMap(payload)
  • sourceMap.payload
  • sourceMap.findEntry(lineNumber, columnNumber)