Introduction détaillée au processus d'implémentation du module dans Node (avec exemples)

Cet article vous apporte une introduction détaillée au processus d'implémentation du module dans Node (avec des exemples). Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

CommonJS définit les modules, exporte et requiert les spécifications des modules Afin d'implémenter cette norme simple, Node.js passe des modules intégrés C/C++ sous-jacents aux modules de base JavaScript, de l'analyse du chemin, du positionnement des fichiers à la compilation. et l’exécution. Il est passé par une série de processus complexes. Une simple compréhension des principes du module Node nous aidera à re-comprendre le framework basé sur Node.

1. Spécification du module CommonJS

La spécification ou la norme CommonJS est simplement une théorie. Elle s'attend à ce que JavaScript ait la capacité de s'exécuter dans des environnements hôtes, pas seulement pour développer le client. les applications peuvent également développer des applications serveur, des outils de ligne de commande, des applications d'interface graphique de bureau, etc.

La définition du module dans la spécification CommonJS est divisée en trois parties :

Définition du module

L'objet module existe dans le module pour représenter le module lui-même. l'attribut exports et la méthode La méthode export peut être définie en la montant sur l'objet exports, par exemple :

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

Référence du module

le module fournit la méthode require() pour introduire le API du module externe dans le contexte actuel :

   var math = require('math')

ID du module

L'ID du module est en fait le paramètre passé à la méthode require(). Il peut s'agir d'une chaîne nommée selon camelCase, ou elle peut l'être. un chemin de fichier.

Node.js s'appuie sur la conception des spécifications CommonJS, en particulier la spécification Modules de CommonJS, pour implémenter un système de modules. En même temps, NPM implémente la spécification Packages de CommonJS. Les modules et les packages constituent la base de. Développement d'applications de nœuds.

2. Principe de chargement du module Node

La spécification du module ci-dessus semble très simple, seul le module, les exportations et les exigences, mais comment Node est-il implémenté ?

Vous devez passer par trois étapes : analyse du chemin (chemin complet du module), emplacement du fichier (extension de fichier ou répertoire), compilation et exécution.

2.1 Analyse du chemin

Review require() reçoit l'identifiant du module en tant que paramètre pour introduire le module. Node effectue une analyse du chemin en fonction de cet identifiant. Différents identifiants adoptent différentes méthodes d'analyse, qui sont principalement divisées dans les catégories suivantes :

Modules de base fournis par Node, tels que http, fs, path

Les modules de base sont compilés lorsque le code source de Node est compilé Il est enregistré en tant que fichier exécutable binaire et est directement chargé dans la mémoire au démarrage du nœud. Il est jugé en premier lors de l'analyse du chemin, la vitesse de chargement est donc très rapide et il n'est pas nécessaire de positionner, de compiler et d'exécuter ultérieurement le fichier. .

Si vous souhaitez charger un module personnalisé portant le même nom que le module principal, comme un module http personnalisé, vous devez utiliser un identifiant différent ou utiliser un chemin à la place.

Modules de fichiers sous forme de chemins, ., .. modules de chemin relatif et modules de chemin /absolu

Les identifiants commençant par ., .. ou / seront traités comme des modules de fichiers, et Node will Le chemin dans require() est converti en chemin réel en tant qu'index, puis compilé et exécuté.

Étant donné que le module de fichiers clarifie l'emplacement du fichier, le temps d'analyse du chemin est raccourci et la vitesse de chargement est aussi lente que celle du module principal.

Les modules personnalisés, c'est-à-dire les modules de fichiers sous forme de chemin

ne sont pas des modules de base, ni des modules de fichiers sous forme de chemin. Les fichiers personnalisés sont des modules de fichiers spéciaux lors de la recherche de chemins. , Les chemins de nœuds dans le chemin du module sont recherchés un niveau à la fois.
Un exemple de stratégie de recherche de chemin de module est le suivant :

// 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' ]

Comme le montre la sortie du tableau de chemin de module dans l'exemple ci-dessus, lors de la recherche d'un module, le répertoire node_modules est recherché niveau par niveau le long du chemin actuel jusqu'au chemin cible. Semblable à la chaîne de prototypes JS ou à la chaîne de portée. Plus le chemin est profond, plus il est lent, donc les modules personnalisés se chargent le plus lentement.

Mécanisme de priorité du cache : Node mettra en cache les modules importés pour améliorer les performances. Contrairement aux navigateurs qui mettent en cache les fichiers, Node met en cache les objets compilés et exécutés, donc require() mettra en cache le même module. Cette priorité du cache est la première priorité, qui est supérieure à la priorité du module principal !

2.2 Emplacement du fichier

Une fois l'analyse du chemin du module terminée, l'emplacement du fichier est terminé, ce qui comprend principalement l'analyse des extensions de fichiers, le traitement des répertoires et des packages. Afin de l'exprimer plus clairement, l'emplacement du fichier est divisé en quatre étapes :

étape 1 : Extension supplémentaire

Habituellement, l'identifiant dans require() n'inclut pas l'extension du fichier. Node essaiera de compléter l'extension dans l'ordre .js, .json et .node.

Lorsque vous essayez d'ajouter une extension, vous devez appeler le module fs pour bloquer de manière synchrone et déterminer si le fichier existe, donc une petite astuce pour améliorer les performances ici est de transmettre les fichiers .json et .node à exiger () avec l'extension Cela accélérera certains.

étape 2 : Traitement du répertoire et recherche pakage.json

Si le fichier correspondant n'est pas trouvé après l'ajout de l'extension, mais qu'un répertoire est obtenu, Node traitera le répertoire comme un package. Selon l'implémentation de la spécification du package CommonJS, Node recherchera pakage.json (fichier de description du package) dans le répertoire, l'analysera dans un objet de description de package via JSON.parse() et prendra le nom de fichier spécifié par l'attribut principal. .

étape 3 : Continuer à rechercher les fichiers d'index par défaut

如果没有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 的文档。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!