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

Когда файл запускается непосредственно из 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

Невозможно require() файлы с расширением .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, даже если в системе есть файл с таким именем.

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

Циклы

При наличии циклических 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 в пределах Node.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'

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

Если идентификатор модуля, переданный в require() , не является модулем core и не начинается с '/', '../', или './', 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
});

Сделав это, 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, см. раздел о сокращении exports.

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, начинающиеся с префикса node:, получат нативный модуль. Используйте с осторожностью!

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

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

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

require.extensions

• <объект>

Инструкции require по обработке определенных расширений файлов.

Обработка файлов с расширением .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: {},
  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 <строка> Путь к модулю, чьи пути поиска требуется получить.
• Возвращает: <массив строк> | <null>

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

Объект module

• <Объект>

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

module.children

• <модуль[]>

Объекты модулей, которые требуются для работы текущего модуля.

module.exports

• <Объект>

Объект 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

• <строка>

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

module.id

• <строка>

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

module.isPreloading

• Тип: <логическое значение> true если модуль выполняется во время фазы предварительной загрузки Node.js.

module.loaded

• <логическое значение>

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

module.parent

• <модуль> | <null> | <undefined>

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

module.path

• <строка>

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

module.paths

• <массив строк>

Пути поиска модуля.

module.require(id)

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

Метод 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)