Detaillierte Einführung in den Modulimplementierungsprozess in Node (mit Beispielen)

Dieser Artikel bietet Ihnen eine detaillierte Einführung in den Modulimplementierungsprozess in Node (mit Beispielen). Ich hoffe, er wird Ihnen als Referenz dienen.

CommonJS definiert Module, Exporte und erfordert Modulspezifikationen. Um diesen einfachen Standard zu implementieren, geht Node.js von zugrunde liegenden integrierten C/C++-Modulen zu JavaScript-Kernmodulen über, von der Pfadanalyse über die Dateipositionierung bis hin zur Kompilierung und Ausführung durchlief es eine Reihe komplexer Prozesse. Ein einfaches Verständnis der Prinzipien des Node-Moduls wird uns helfen, das auf Node basierende Framework neu zu verstehen.

1. CommonJS-Modulspezifikation

CommonJS-Spezifikation oder -Standard ist lediglich eine Theorie. Sie erwartet, dass JavaScript in der Lage ist, in Hostumgebungen ausgeführt zu werden, und nicht nur, um Clients zu entwickeln Anwendungen können auch Serveranwendungen, Befehlszeilentools, grafische Desktop-Schnittstellenanwendungen usw. entwickeln.

Die Moduldefinition in der CommonJS-Spezifikation ist in drei Teile unterteilt:

Moduldefinition

Das Modulobjekt ist im Modul vorhanden, um das Modul selbst darzustellen das Export-Attribut und die Methode. Die Export-Methode kann definiert werden, indem sie auf dem Export-Objekt gemountet wird, zum Beispiel:

    // math.js
   exports.add = function(){ //...}

Modulreferenz

Modul stellt die Methode require() zur Einführung der API von bereit das externe Modul in den aktuellen Kontext:

   var math = require('math')

Die Modulidentifikation ist eigentlich der Parameter, der an die require()-Methode übergeben wird. Es kann sich um eine Zeichenfolge handeln, die nach camelCase benannt ist, oder um einen Dateipfad.

Node.js greift auf das Design der CommonJS-Spezifikationen zurück, insbesondere auf die Modules-Spezifikation von CommonJS, um ein Modulsystem zu implementieren. Gleichzeitig implementiert NPM die Packages-Spezifikation von CommonJS Entwicklung von Knotenanwendungen.

2. Prinzip des Ladens von Node-Modulen

Die obige Modulspezifikation scheint sehr einfach zu sein, nur Module, Exporte und Anforderungen, aber wie wird Node implementiert?

Sie müssen drei Schritte durchlaufen: Pfadanalyse (vollständiger Pfad des Moduls), Dateispeicherort (Dateierweiterung oder Verzeichnis) sowie Kompilierung und Ausführung.

2.1 Pfadanalyse

Review require() empfängt die Modulkennung als Parameter, um das Modul einzuführen. Der Knoten führt eine Pfadanalyse basierend auf dieser Kennung durch. Verschiedene Bezeichner verwenden unterschiedliche Analysemethoden, die hauptsächlich in die folgenden Kategorien unterteilt sind:

Von Node bereitgestellte Kernmodule wie http, fs, path

Die Kernmodule werden beim Node-Quellcode kompiliert wird kompiliert Es wird als binäre ausführbare Datei gespeichert und beim Start des Knotens direkt in den Speicher geladen. Es wird zuerst in der Pfadanalyse beurteilt, sodass die Ladegeschwindigkeit sehr hoch ist und keine anschließende Dateipositionierung, Kompilierung und Ausführung erforderlich ist .

Wenn Sie ein benutzerdefiniertes Modul mit demselben Namen wie das Kernmodul laden möchten, beispielsweise ein benutzerdefiniertes http-Modul, müssen Sie einen anderen Bezeichner oder stattdessen einen Pfad verwenden.

Dateimodule in Form von Pfaden, ., .. relative Pfadmodule und /absolute Pfadmodule

Bezeichner, die mit ., .. oder / beginnen, werden als Dateimodule und Node behandelt wird Der Pfad in require() wird als Index in den tatsächlichen Pfad konvertiert und dann kompiliert und ausgeführt.

Da das Dateimodul den Dateispeicherort klärt, wird die Pfadanalysezeit verkürzt und die Ladegeschwindigkeit ist nur langsamer als die des Kernmoduls.

Benutzerdefinierte Module, also Dateimodule in Nicht-Pfadform

, sind keine Kernmodule, und auch keine Dateimodule in Pfadform. Benutzerdefinierte Dateien sind spezielle Dateimodule bei der Suche nach Pfaden , Knotenpfade innerhalb des Modulpfads werden Ebene für Ebene durchsucht.
Ein Beispiel für die Modulpfad-Suchstrategie lautet wie folgt:

// paths.js
console.log(module.paths)

// Terminal
$ node paths.js
[ '/Users/tong/WebstormProjects/testNode/node_modules',
'/Users/tong/WebstormProjects/node_modules',
'/Users/tong/node_modules',
'/Users/node_modules',
'/node_modules' ]

Aus der Modulpfad-Array-Ausgabe im obigen Beispiel ist ersichtlich, dass bei der Suche nach Modulen das Verzeichnis node_modules stufenweise durchsucht wird Ebene entlang des aktuellen Pfads, bis der Zielpfad erreicht ist, ähnlich der JS-Prototyp-Kette oder der Scope-Kette. Je tiefer der Pfad, desto langsamer ist er, sodass benutzerdefinierte Module am langsamsten geladen werden.

Cache-Prioritätsmechanismus: Node speichert importierte Module zwischen, um die Leistung zu verbessern. Im Gegensatz zu Browsern, die Dateien zwischenspeichern, speichert require() dasselbe Modul zwischen. Diese Cache-Priorität ist die erste Priorität, die höher ist als die Priorität des Kernmoduls!

2.2 Dateispeicherort

Nach Abschluss der Modulpfadanalyse ist der Dateispeicherort abgeschlossen, der hauptsächlich die Dateierweiterungsanalyse sowie die Verzeichnis- und Paketverarbeitung umfasst. Um es klarer auszudrücken, ist der Dateispeicherort in vier Schritte unterteilt:

Schritt 1: Ergänzende Erweiterung

Normalerweise enthält der Bezeichner in require() nicht die Dateierweiterung. Node wird versuchen, die Erweiterung in der Reihenfolge .js, .json und .node zu ergänzen.

Wenn Sie versuchen, eine Erweiterung hinzuzufügen, müssen Sie das fs-Modul aufrufen, um synchron zu blockieren und festzustellen, ob die Datei vorhanden ist. Ein kleiner Trick zur Verbesserung der Leistung besteht hier also darin, die .json- und .node-Dateien an die Anforderung zu übergeben () mit der Erweiterung wird es etwas beschleunigen.

Schritt 2: Verzeichnisverarbeitung und Suche nach pakage.json

Wenn die entsprechende Datei nach dem Hinzufügen der Erweiterung nicht gefunden wird, aber ein Verzeichnis erhalten wird, behandelt Node das Verzeichnis als Paket. Gemäß der Implementierung der CommonJS-Paketspezifikation sucht Node im Verzeichnis nach pakage.json (Paketbeschreibungsdatei), analysiert es über JSON.parse() in ein Paketbeschreibungsobjekt und übernimmt den durch das Hauptattribut angegebenen Dateinamen .

Schritt 3: Standardmäßig weiterhin nach Indexdateien suchen

如果没有pakage.json或者main属性指定的文件名错误，那 Node 会将 index 当做默认文件名，依次查找 index.js、index.json、index.node

step4: 进入下一个模块路径

在上述目录分析过程中没有成功定位时，自定义模块按路径查找策略进入上一层node_modules目录，当整个模块路径数组遍历完毕后没有定位到文件，则会抛出查找失败异常。

缓存加载的优化策略使得二次引入不需要路径分析、文件定位、编译执行这些过程，而且核心模块也不需要文件定位的过程，这大大提高了再次加载模块时的效率

2.3 编译执行

Node 中每个模块都是一个对象，在具体定位到文件后，Node 会新建该模块对象，然后根据路径载入并编译。不同的文件扩展名载入方法为：

.js 文件: 通过 fs 模块同步读取后编译执行.json 文件: 通过 fs 模块同步读取后，用JSON.parse()解析并返回结果.node 文件: 这是用 C/C++ 写的扩展文件，通过process.dlopen()方法加载最后编译生成的其他扩展名: 都被当做 js 文件载入

载入成功后 Node 会调用具体的编译方式将文件执行后返回给调用者。对于 .json 文件的编译最简单，JSON.parse()解析得到对象后直接赋值给模块对象的exports，而 .node 文件是C/C++编译生成的，Node 直接调用process.dlopen()载入执行就可以，下面重点介绍 .js 文件的编译：

在 CommonJS 模块规范中有module、exports 和 require 这3个变量，在 Node API 文档中每个模块还有 __filename、__dirname这两个变量，但是在模块中没有定义这些变量，那它们是怎么产生的呢？

事实上在编译过程中，Node 对每个 JS 文件都被进行了封装，例如一个 JS 文件会被封装成如下：

(function (exports, require, module, __filename, __dirname) {
    var math = require('math')
    export.add = function(){ //... }
})

首先每个模块文件之间都进行了作用域隔离，通过vm原生模块的runInThisContext()方法（类似 eval）返回一个具体的 function 对象，最后将当前模块对象的exports属性、require()方法、模块对象本身module、文件定位时得到的完整路径__filename和文件目录__dirname作为参数传递给这个 function 执行。模块的exports属性上的任何方法和属性都可以被外部调用，其余的则不可被调用。

至此，module、exports 和 require的流程就介绍完了。

曾经困惑过，每个模块都可以使用exports的情况下，为什么还必须用module.exports。

这是因为exports在编译过程中时通过形参传入的，直接给exports形参赋值只改变形参的引用，不能改变作用域外的值，例如：

let change = function (exports) {
  exports = 100
  console.log(exports)
}

var exports = 2
change(exports) // 100
console.log(exports) // 2

所以直接赋值给module.exports对象就不会改变形参的引用了。

编译成功的模块会将文件路径作为索引缓存在 Module._cache 对象上，路径分析时优先查找缓存，提高二次引入的性能。

三、Node 核心模块

总结来说 Node 模块分为Node提供的核心模块和用户编写的文件模块。文件模块是在运行时动态加载，包括了上述完整的路径分析、文件定位、编译执行这些过程，核心模块在Node源码编译成可执行文件时存为二进制文件，直接加载在内存中，所以不用文件定位和编译执行。

核心模块分为 C/C++ 编写的和 JavaScript 编写的两部分，在编译所有 C/C++ 文件之前，编译程序需要将所有的 JavaScript 核心模块编译为 C/C++ 可执行代码，编译成功的则放在 NativeModule._cache对象上，显然和文件模块 Module._cache的缓存位置不同。

在核心模块中，有些模块由纯 C/C++ 编写的内建模块，主要提供 API 给 JavaScript 核心模块，通常不能被用户直接调用，而有些模块由  C/C++ 完成核心部分，而 JavaScript 实现封装和向外导出，如 buffer、fs、os 等。

所以在Node的模块类型中存在依赖层级关系：内建模块（C/C++）—> 核心模块（JavaScript）—> 文件模块。

使用require()十分的方便，但从 JavaScript 到 C/C++ 的过程十分复杂，总结来说需要经历 C/C++ 层面内建模块的定义、（JavaScript）核心模块的定义和引入以及（JavaScript）文件模块的引入。

四、前端模块规范

对比前后端的 JavaScript，浏览器端的 JavaScript 需要经历从同一个服务器端分发到多个客户端执行，通过网络加载代码，瓶颈在于宽带；而服务器端 JavaScript 相同代码需要多次执行，通过磁盘加载，瓶颈在于 CPU 和内存，所以前后端的 JavaScript 在 Http 两端的职责完全不用。

Node 模块的引入几乎是同步的，而前端模块如果同步引入，那脚本加载需要太长的时间，所以 CommonJS 为后端 JavaScript 制定的规范不适合前端。而后出现 AMD 和 CMD 用于前端应用场景。

4.1 AMD 规范

AMD 即异步模块定义（Asynchronous Module Definition）,模块定义为：

define(id?, dependencies?, factory);

AMD 模块需要用define明确定义一个模块，其中模块id与依赖dependencies是可选的，factory的内容就是实际代码的内容。例如指定一些依赖到模块中：

define(['dep1', 'dep2'], function(){
    // module code
});

require.js 实现 AMD 规范的模块化，感兴趣的可以查看 require.js 的文档。

4.2 CMD 规范

CMD 模块的定义更加简单：

 define(factory);

定义的模块同 Node 模块一样是隐式包装，在依赖部分支持动态引入，例如：

 define(function(require, exports, module){
     // module code
 });

require、exports、module通过形参传递给模块，需要依赖模块时直接使用require()引入。

sea.js 实现 AMD 规范的模块化，感兴趣的可以查看 sea.js 的文档。

Das obige ist der detaillierte Inhalt vonDetaillierte Einführung in den Modulimplementierungsprozess in Node (mit Beispielen). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!