Notes d'étude sur le mécanisme de module dans Node.js_node.js

Depuis la naissance de Javascript, personne ne l'a jamais considéré comme un langage de programmation. À l'ère du Web 1.0, ce langage de script était principalement utilisé pour la validation de formulaires et les effets spéciaux de pages Web. Ce n'est qu'à l'ère du Web 2.0, lorsque les ingénieurs front-end l'ont utilisé pour améliorer considérablement l'expérience utilisateur sur les pages Web, que JS a été largement apprécié. À mesure que JS devient de plus en plus populaire, il a subi des modifications dans les bibliothèques d'outils, les bibliothèques de composants, les frameworks frontaux et les applications frontales. Javascript manque intrinsèquement d'une fonctionnalité : les modules, et l'émergence de la spécification CommonJS compense cette lacune. Cet article présentera la spécification CommonJS et le mécanisme de module de Node.

Parmi d'autres langages de haut niveau, Java a des fichiers de classe, Python a un mécanisme d'importation et PHP a include et require. La façon dont JS introduit le code via la balise Dans le passé, les utilisateurs devaient utiliser des espaces de noms et d'autres méthodes pour contraindre artificiellement le code. Ce n'est qu'avec l'émergence de la spécification CommonJS que le Javascript front-end et back-end a pu être unifié. Node s'appuie sur la spécification Modules de CommonJS pour implémenter un système de modules très facile à utiliser.

1. Spécification du module CommonJS

La spécification du module CommonJS est divisée en 3 parties :

1). Référence du module : introduisez l'API d'un module dans le contexte actuel via la méthode require() et transmettez un identifiant de module, tel que var math = require('math'); 2).Définition du module : Exportez les méthodes ou variables du module actuel via l'objet exports. Il existe également un objet module dans le module, et les exportations sont en fait des attributs du module. Dans Node, un fichier est un module et les "variables globales" du module ne sont pas visibles par le monde extérieur. Seuls les attributs montés sur les exportations sont publics, tels que exports.add = function() {} ; = 3.1415926; 3) Identification du module : il s'agit en fait du paramètre passé à require(), comme le "math" ci-dessus, qui doit être une chaîne conforme à la nomenclature camel, ou un chemin relatif commençant par ".." ou Chemin absolu, il ne peut avoir aucun suffixe de nom de fichier ".js"

2. Processus de mise en œuvre du module de nœud

Dans Node, les modules sont divisés en deux catégories : l'une est le module de base fourni par Node lui-même et l'autre est le module de fichier écrit par l'utilisateur. Une partie du module principal est compilée dans un fichier binaire lors du processus de compilation du code source de Node. Le module principal est chargé directement dans la mémoire au démarrage de Node, sa vitesse de chargement est donc la plus rapide. Le module de fichiers est chargé dynamiquement au moment de l'exécution et nécessite trois étapes : analyse du chemin, emplacement du fichier, compilation et exécution. Notez que Node met en cache les modules importés pour réduire le coût de l'introduction secondaire et adopte la stratégie de chargement à partir du cache avec la priorité la plus élevée pour le chargement secondaire du même module.

2.1 Analyse du chemin

L'analyse des chemins analyse principalement les identifiants de modules mentionnés ci-dessus, qui sont principalement répartis dans les catégories suivantes :

1), modules de base, tels que http, fs, path, etc. 2) Module de fichier de chemin relatif commençant par, .. 3). Module de fichier de chemin absolu commençant par / 4) Module de fichier personnalisé, qui peut se présenter sous la forme d'un fichier ou d'un package. Node essaiera de trouver le fichier cible un par un en fonction du tableau de chemin du module module.paths. Il recherche généralement le répertoire nommé node_modules étape par étape jusqu'au répertoire racine, c'est donc la méthode la plus longue. pour le trouver.

2.2 Positionnement des fichiers

Sur la base de l'analyse du chemin, l'emplacement du fichier doit prêter attention aux détails suivants :

1) Analyse des extensions de fichiers : étant donné que la spécification CommonJS permet à l'identifiant du module de ne pas remplir l'extension, Node remplira l'extension dans l'ordre .js, .json et .node, et essaiera dans l'ordre 2) Analyse du répertoire et packages : Si le fichier correspondant n'est pas trouvé après l'analyse d'extension de fichier ci-dessus, mais qu'un répertoire est obtenu, Node traitera le répertoire comme un package

2.3 Compilation et exécution

Après avoir localisé le fichier spécifique, Node créera un nouvel objet module, le chargera et le compilera selon le chemin. Pour différentes extensions, la méthode de chargement est différente :

1), fichier .js : lit le fichier de manière synchrone via le module fs et compile et exécute 2). Fichier .node : Il s'agit d'un fichier d'extension écrit en C/C et chargé via la méthode dlopen() Fichier 3).json : lisez le fichier de manière synchrone via le module fs et utilisez JSON.parse() pour analyser et renvoyer le résultat 4). Autres fichiers d'extension : sont chargés sous forme de fichiers .js

Nous savons que chaque fichier de module a trois variables : require, exports et module par défaut. Même dans la documentation de l'API de Node, nous savons que chaque module a également deux variables : filename et dirname. Comment le module de Node s'assure-t-il que les « variables globales » déclarées ne contaminent pas réellement les autres modules ? En fait, Node encapsulera le contenu du fichier en tête et en queue lors de la compilation des modules JS. Voici un exemple de fichier JS avec packaging tête et queue :

Copier le code Le code est le suivant : (function(exports, require, module, __filename, __dirname) { /* Le milieu est le contenu réel du fichier JS */ var math = require('math'); exports.area = fonction (rayon) { return Math.PI * rayon * rayon ; }; /* Le contenu réel du fichier JS se termine */ }); De cette façon, chaque fichier de module est isolé de la portée et des variables telles que require, exports et module sont également injectées dans le contexte du module. Il s'agit de l'implémentation par Node de la spécification du module CommonJS. Le processus de compilation des modules C/C et des modules Node core est relativement compliqué et ne sera pas décrit en détail.

3. Pile d'appels du module

Il est nécessaire de clarifier la relation d'appel des différents modules dans Node, comme le montre la figure ci-dessous :

Le module intégré C/C est le module le plus bas et est un module de base. Il fournit principalement des API pour les modules de base Javascript et les modules de fichiers Javascript tiers à appeler. Le module principal Javascript a deux responsabilités principales : l'une est de servir de couche d'encapsulation et de couche de pontage du module intégré C/C pour les appels de module de fichiers, et l'autre est un module purement fonctionnel qui n'a pas besoin de gérer le couche inférieure. Les modules de fichiers sont généralement écrits par des tiers, y compris les modules Javascript ordinaires et les modules d'extension C/C.

4. Forfaits et NPM

4.1 Structure du package

Un package est essentiellement un fichier d'archive (généralement .zip ou .tar.gz), qui peut être décompressé et restauré dans un répertoire après l'installation. La spécification du package CommonJS se compose de deux parties : la structure du package et le fichier de description du package. Une structure de package entièrement conforme à la spécification CommonJS doit contenir les fichiers suivants :

1).package.json : fichier de description du package 2).bin : répertoire où sont stockés les fichiers binaires exécutables 3).lib : Répertoire pour stocker le code Javascript 4).doc : Répertoire de stockage des documents 5).test : Répertoire pour stocker les cas de tests unitaires

4.2 Fichier de description du package

Le fichier de description du package est un fichier JSON - package.json, situé dans le répertoire racine du package. Il constitue une partie importante du package et est utilisé pour décrire les informations générales du package. Tous les comportements de NPM qui seront mentionnés plus loin sont étroitement liés aux champs de ce fichier. Ce qui suit utilise le fichier package.json du projet Web Framework Express bien connu comme exemple pour illustrer la signification de certains champs courants.

1).name : nom du package 2).description : présentation du package 3).version : numéro de version, qui doit être conforme au "contrôle de version sémantique", voir http://semver.org/ 4).dépendances : liste des packages requis pour utiliser le package actuel. Cet attribut est très important. NPM chargera automatiquement les packages dépendants via cet attribut . 5).dépôts : Liste des emplacements où le code source est hébergé

Pour l'utilisation d'autres champs, veuillez vous référer à la description du package.json NPM

4.3 Fonctions communes du NPM

NPM (node package manager), généralement appelé gestionnaire de packages de nœuds. Sa fonction principale est de gérer les packages de nœuds, notamment : l'installation, la désinstallation, la mise à jour, l'affichage, la recherche, la publication, etc.

4.3.1 Installation du package NPM

Il existe deux types d'installation des packages Node : l'installation locale et l'installation globale. La différence entre les deux est la suivante :

1). Installation locale npm install : Le package sera téléchargé dans le répertoire courant et ne pourra être utilisé que dans le répertoire courant. 2). Installation globale npm install -g : le package sera téléchargé dans un répertoire système spécifique et le package installé pourra être utilisé dans tous les répertoires.

4.3.2 Gestion des packages NPM

Ce qui suit prend grunt-cli (outil de ligne de commande grunt) comme exemple pour répertorier les commandes de gestion de packages couramment utilisées :

1).npm install : Installer tous les packages déclarés dans les champs dependencies et devDependencies du fichier package.json 2).npm install grunt-cli@0.1.9 : Installer une version spécifique de grunt-cli 3).npm install grunt-contrib-copy --save : installez grunt-contrib-copy et enregistrez la dépendance dans le fichier package.json 4).npm uninstall grunt-cli : Désinstaller le package 5).npm list : Vérifiez quels packages sont installés 6).npm submit ：Publier le package