Модули: модули CommonJS¶
Стабильность: 2 - стабильная
В модульной системе 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
расширение¶
Невозможно 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
.
Это степень осознания 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()
это не основной модуль и не начинается с '/'
, '../'
, или './'
, то 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
.
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:
-prefixed require вызовы будут получать собственный модуль. Используйте осторожно!
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
¶
Стабильность: 0 - устарело
- {Объект}
Инструктировать 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
{string []} Пути для определения местоположения модуля. Если присутствует, эти пути используются вместо путей разрешения по умолчанию, за исключением GLOBAL_FOLDERS нравиться$HOME/.node_modules
, которые всегда включены. Каждый из этих путей используется в качестве отправной точки для алгоритма разрешения модуля, что означает, чтоnode_modules
иерархия проверяется из этого места.- Возвращает: {строка}
Используйте внутренний require()
машины для поиска местоположения модуля, но вместо загрузки модуля просто верните разрешенное имя файла.
Если модуль не может быть найден, MODULE_NOT_FOUND
выдается ошибка.
require.resolve.paths(request)
¶
request
{строка} Путь к модулю, пути поиска которого извлекаются.- Возвращает: {string [] | null}
Возвращает массив, содержащий пути, найденные во время разрешения request
или null
если request
строка ссылается на основной модуль, например http
или fs
.
В module
объект¶
- {Объект}
В каждом модуле module
свободная переменная - это ссылка на объект, представляющий текущий модуль. Для удобства, module.exports
также доступен через 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
¶
Стабильность: 0 - Не рекомендуется: используйте
require.main
а такжеmodule.children
вместо.
- {модуль | null | неопределенный}
Модуль, который первым требовал этого, или 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
основной модуль.
Поддержка Source Map v3¶
Этот раздел был перемещен в Модули: module
основной модуль.
module.findSourceMap(path)
- Класс:
module.SourceMap
new SourceMap(payload)
sourceMap.payload
sourceMap.findEntry(lineNumber, columnNumber)