Включение

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.

Чтобы сделать модули доступными для REPL Node.js, может быть полезно также добавить папку /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, следует избегать зависимости от него.

Результатом, возвращаемым 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 = DIRS + DIR
   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, даже если существует файл с таким именем.

Список всех встроенных модулей можно получить из module.builtinModules. Все модули перечислены без префикса node:, за исключением тех, для которых такой префикс обязателен (как описано в следующем разделе).

Циклические зависимости

При наличии циклических вызовов 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)