Модули: Модули CommonJS

В системе модулей Node.js каждый файл рассматривается как отдельный модуль. Например, рассмотрим файл с именем foo.js:

const circle = require('./circle.js');
console.log(`The area of a circle of radius 4 is ${circle.area(4)}`);

В первой строке foo.js загружает модуль circle.js, который находится в той же директории, что и foo.js.

Вот содержимое circle.js:

const { PI } = Math;

exports.area = (r) => PI * r ** 2;

exports.circumference = (r) => 2 * PI * r;

Модуль circle.js экспортировал функции area() и circumference(). Функции и объекты добавляются в корень модуля путем указания дополнительных свойств в специальном объекте exports.

Переменные, локальные для модуля, будут приватными, потому что модуль обернут в функцию Node.js (см. обёртку модуля). В этом примере переменная PI является приватной для circle.js.

Свойству module.exports можно присвоить новое значение (например, функцию или объект).

Ниже bar.js использует модуль square, который экспортирует класс Square:

const Square = require('./square.js');
const mySquare = new Square(2);
console.log(`The area of mySquare is ${mySquare.area()}`);

Модуль square определён в square.js:

// Assigning to exports will not modify module, must use module.exports
module.exports = class Square {
  constructor(width) {
    this.width = width;
  }

  area() {
    return this.width ** 2;
  }
};

Система модулей реализована в модуле require('module').

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

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

Для файла foo.js, это будет true при запуске через node foo.js, но false при запуске через require('./foo').

Поскольку module предоставляет свойство filename (обычно эквивалентное __filename), точку входа текущего приложения можно получить, проверив require.main.filename.

Дополнительные сведения: Советы по менеджерам пакетов

Семантика функции 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(), сами пакеты могут находиться где угодно.

Дополнительные сведения: Расширение .mjs

Невозможно загрузить файлы с расширением .mjs. Попытка сделать это вызовет ошибку. Расширение .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 filesystem 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 = [GLOBAL_FOLDERS]
4. while I >= 0,
   a. if PARTS[I] = "node_modules" CONTINUE
   b. DIR = path join(PARTS[0 .. I] + "node_modules")
   c. DIRS = DIRS + DIR
   d. let I = I - 1
5. return DIRS

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, EXACT } = MATCH
2. let RESOLVED_PATH = fileURLToPath(RESOLVED)
3. If EXACT is true,
   a. If the file at RESOLVED_PATH exists, load RESOLVED_PATH as its extension
      format. STOP
4. Otherwise, if EXACT is false,
   a. LOAD_AS_FILE(RESOLVED_PATH)
   b. LOAD_AS_DIRECTORY(RESOLVED_PATH)
5. THROW "not found"

Кэширование

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

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

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

Ограничения кэширования модулей

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

Кроме того, в системах с регистронезависимыми файловыми системами или операционными системами разные разрешённые имена файлов могут указывать на один и тот же файл, но кэш всё равно будет обрабатывать их как разные модули и будет загружать файл несколько раз. Например, require('./foo') и require('./FOO') возвращают два разных объекта, независимо от того, являются ли ./foo и ./FOO одним и тем же файлом.

Ядерные модули

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

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

Ядерные модули всегда предпочтительны для загрузки, если их идентификатор передаётся в require(). Например, require('http') всегда вернёт встроенный модуль HTTP, даже если существует файл с таким именем.

Циклы

Когда существуют циклические 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');

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

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

Когда 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

Необходимо тщательно спланировать работу циклических зависимостей модулей в приложении.

Файловые модули

Если точное имя файла не найдено, Node.js попытается загрузить необходимый файл с добавлением расширений: .js, .json, и, наконец, .node.

Файлы с расширением .js интерпретируются как текстовые файлы JavaScript, файлы с расширением .json парсятся как текстовые файлы JSON. Файлы с расширением .node интерпретируются как скомпилированные модули плагинов, загружаемые с помощью process.dlopen().

Модуль, требующий файл, начинающийся с '/', представляет собой абсолютный путь к файлу. Например, require('/home/marco/foo.js') загрузит файл по пути /home/marco/foo.js.

Требуемый модуль, начинающийся с './', является относительным по отношению к файлу, вызывающему require(). То есть, circle.js должен находиться в той же директории, что и foo.js для того, чтобы require('./circle') его обнаружил.

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

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

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

Удобно организовывать программы и библиотеки в автономные директории и предоставлять к ним единый входной пункт. Существует три способа передачи папки в require() в качестве аргумента.

Первый — создать файл package.json в корне папки, в котором указан модуль main. Пример файла package.json может выглядеть так:

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

Если он находился в папке по адресу ./some-library, то require('./some-library') попытался бы загрузить ./some-library/lib/some-library.js.

Это всё, что Node.js знает о файлах package.json.

Если файл 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'

Загрузка из папок node_modules

Если идентификатор модуля, переданный в require(), не является модулем ядра core, и не начинается с '/', '../', или './', тогда Node.js начинает поиск в родительском каталоге текущего модуля, добавляет /node_modules, и пытается загрузить модуль из этого расположения. Node.js не будет добавлять node_modules к пути, уже заканчивающемуся на node_modules.

Если модуль не найден там, то Node.js переходит к родительскому каталогу и так далее, пока не достигнет корня файловой системы.

Например, если файл по адресу '/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.js ищет 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
});

С помощью этого Node.js достигает нескольких целей:

• Переменные верхнего уровня (определённые с помощью var, const или let) ограничиваются модулем, а не глобальным объектом.
• Это помогает предоставить некоторые глобально выглядящие переменные, которые на самом деле специфичны для модуля, такие как:
  • Объекты module и exports, которые разработчик может использовать для экспорта значений из модуля.
  • Удобные переменные __filename и __dirname, содержащие абсолютный путь к файлу модуля и пути к каталогу.

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

__dirname

• <строка>

Имя каталога текущего модуля. Это то же самое, что и path.dirname() файла __filename.

Пример: запуск node example.js из /Users/mjr

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

__filename

• <строка>

Имя файла текущего модуля. Это абсолютный путь к текущему файлу модуля с разрешёнными символическими ссылками.

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

См. __dirname для получения имени каталога текущего модуля.

Примеры:

Запуск node example.js из /Users/mjr

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

Предположим два модуля: a и b, где b является зависимостью от a, и существует структура каталогов:

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

Ссылки на __filename внутри b.js вернут /Users/mjr/app/node_modules/b/b.js, в то время как ссылки на __filename внутри a.js вернут /Users/mjr/app/a.js.

exports

• <Объект>

Ссылка на module.exports, которая короче для набора. Подробности о том, когда использовать exports и когда использовать module.exports, см. в разделе о экспорте shortcut.

module

• <модуль>

Ссылка на текущий модуль, см. раздел о объекте module. В частности, module.exports используется для определения того, что экспортирует модуль, и что доступно через require().

require(id)

• id <строка> имя или путь модуля
• Возвращает: <любой> содержимое экспортированного модуля

Используется для импорта модулей, JSON, и локальных файлов. Модули можно импортировать из node_modules. Локальные модули и JSON-файлы можно импортировать, используя относительный путь (например, ./, ./foo, ./bar/baz, ../foo). Он будет разрешён относительно каталога, указанного в __dirname (если определён) или текущем рабочем каталоге. Относительные пути в стиле POSIX разрешаются независимо от ОС, то есть примеры выше будут работать в Windows так же, как и в системах Unix.

// 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('crypto');

require.cache

• <Объект>

Модули кэшируются в этом объекте при их запросе. Удаление пары ключ-значение из этого объекта приведет к перезагрузке модуля при следующем require. Это не относится к нативным дополнениям, для которых перезагрузка приведёт к ошибке.

Также возможно добавление или замена записей. Этот кэш проверяется перед нативными модулями, и если имя, соответствующее нативному модулю, добавлено в кэш, вызов require больше не получит нативный модуль. Используйте с осторожностью!

require.extensions

• <Объект>

Указывает Node.js, как обрабатывать определённые расширения файлов.

Обрабатывайте файлы с расширением .sjs как .js.

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

Устарело. В прошлом этот список использовался для загрузки не-JavaScript-модулей в Node.js путём компиляции по запросу. Однако на практике существуют намного лучшие способы сделать это, например, загрузить модули через какую-либо другую программу Node.js или скомпилировать их в JavaScript заранее.

Избегайте использования require.extensions. Это может привести к скрытым ошибкам, а разрешение расширений становится медленнее с каждым зарегистрированным расширением.

require.main

• <модуль>

Объект Module, представляющий скрипт входа, загруженный при запуске процесса Node.js. См. "Доступ к главному модулю".

В скрипте entry.js:

console.log(require.main);

node entry.js

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

require.resolve(request[, options])

• request <строка> Путь модуля для разрешения.
• options <объект>
  • paths <массив строк> Пути для разрешения расположения модуля. Если указаны, используются вместо стандартных путей разрешения, за исключением GLOBAL_FOLDERS таких как $HOME/.node_modules, которые всегда включаются. Каждый из этих путей используется в качестве начальной точки для алгоритма разрешения модулей, то есть иерархия node_modules проверяется из этого расположения.
• Возвращает: <строка>

Использует внутренние механизмы require() для поиска расположения модуля, но вместо загрузки модуля просто возвращает разрешённое имя файла.

Если модуль не найден, выбрасывается ошибка MODULE_NOT_FOUND.

require.resolve.paths(request)

• request <string> Путь к модулю, для которого извлекаются пути поиска.
• Возвращает: <string[]> | <null>

Возвращает массив, содержащий пути, которые были просмотрены во время разрешения request или null, если строка request ссылается на основной модуль, например, http или fs.

Объект module

• <Object>

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

module.children

• <module[]>

Объекты модулей, которые впервые потребовались этим модулем.

module.exports

• <Object>

Объект module.exports создаётся системой Module. Иногда это неудобно; многие хотят, чтобы их модуль был экземпляром какого-либо класса. Для этого присвойте желаемый объект экспорта module.exports. Присвоение желаемого объекта exports просто переопределяет локальную переменную exports, что вероятно нежелательно.

Например, предположим, что мы создаём модуль под названием a.js:

const EventEmitter = require('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);

Затем в другом файле мы можем сделать:

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

Присвоение module.exports должно быть выполнено немедленно. Его нельзя выполнять в каких-либо коллбеках. Это не работает:

x.js:

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

y.js:

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

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

Когда свойство module.exports полностью заменяется новым объектом, обычно также переопределяется exports:

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

Чтобы проиллюстрировать поведение, представьте эту гипотетическую реализацию 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;
}

module.filename

• <string>

Полное разрешенное имя файла модуля.

module.id

• <string>

Идентификатор модуля. Обычно это полное разрешенное имя файла.

module.loaded

• <boolean>

Загружен ли модуль или находится в процессе загрузки.

module.parent

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

Модуль, который первоначально потребовал этого модуля, или null, если текущий модуль является точкой входа в текущий процесс, или undefined, если модуль был загружен чем-то, что не является модулем CommonJS (например, REPL или import).

module.path

• <string>

Имя каталога модуля. Обычно это то же самое, что и path.dirname() для module.id.

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.createRequireFromPath(filename)
• module.syncBuiltinESMExports()

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

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

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