Résumé de l'utilisation des spécifications du module CommonJS dans Node.js

Javascript manque intrinsèquement d'une fonctionnalité : les modules, et l'émergence de la spécification CommonJS compense cette lacune. Avec l'émergence de la spécification CommonJS, Javascript front-end et back-end peut ê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). require () et transmettez un identifiant de module pour introduire l'API d'un module dans le contexte actuel, tel que var math = require('math');
2). exporte un objet ou une variable. 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 commencer par "." .." Le chemin relatif ou le chemin absolu au début, il ne peut pas avoir le suffixe de nom de fichier ".js"

2. Processus d'implémentation du module de nœud

Dans Node, le module est divisé en deux classes : un type est le module de base fourni par Node lui-même et l'autre type 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 du chemin analyse principalement les identifiants de module mentionnés ci-dessus, qui sont principalement répartis dans les catégories suivantes :

1), noyau Modules, tels que http, fs, chemin, etc.
2), modules de fichiers de chemin relatif commençant par . ou ..
3), modules de fichiers de chemin absolu commençant par /
4), modules de fichiers personnalisés , 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 Emplacement du fichier

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

1), analyse de l'extension de fichier : en raison de la spécification CommonJS, l'identifiant du module ne remplit pas l'extension. Node remplira l'extension dans l'ordre .js, .json et .node, et essaiera
2), analyse du répertoire et package dans l'ordre. : Si aucune recherche n'est trouvée après l'analyse d'extension de fichier ci-dessus sur le fichier correspondant, mais obtient un répertoire, Node traitera le répertoire comme un package

2.3 Compiler et exécuter

Après avoir localisé le fichier spécifique, Node créera un nouveau module Object, chargé et compilé selon le chemin. Pour différentes extensions, les méthodes de chargement sont différentes :

1), fichier .js : lire le fichier de manière synchrone via le module fs et compiler et exécuter
2), fichier .node : cela utilise C/ Les fichiers d'extension écrits en C++ sont chargés via la méthode dlopen()
3), fichiers .json : lisez le fichier de manière synchrone via le module fs et utilisez JSON.parse() pour analyser et renvoyer le résultat
4) , et 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. Il existe deux variables, le nom de fichier et le nom de répertoire. D'où viennent-elles ? 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 un packaging head et tail :

(function(exports, require, module, __filename, __dirname) {
    /* 中间是JS文件的实际内容 */
    var math = require('math');
    exports.area = function(radius) {
        return Math.PI * radius * radius;
    };
    /* JS文件的实际内容结束 */
});

De cette façon, chaque fichier de module a une isolation de portée et des variables telles que require, exports et module sont également injectées dans le contexte du module parmi. 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 principaux Node est relativement compliqué et ne sera pas décrit en détail.

3. Pile d'appels de 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 de niveau 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. les modules ne sont presque jamais exposés. Le module principal Javascript a deux responsabilités principales : l'une est de servir de couche d'encapsulation et de couche de pontage des modules intégrés C/C++ pour les appels de modules de fichiers, et l'autre est un module purement fonctionnel qui n'a pas besoin de s'occuper du fond. couche. Les modules de fichiers sont généralement écrits par des tiers, notamment les modules Javascript ordinaires et les modules d'extension C/C++.

4. Packages et NPM

4.1 Structure des packages

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 de stockage du code Javascript
4).doc : Répertoire de stockage des documents
5).test : Répertoire de stockage des cas de tests unitaires

4.2 Fichier de description du package

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. C'est 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 : Introduction du package

3).version : Numéro de version, doit se conformer au "contrôle de version sémantique", reportez-vous à http:// semver .org/

4).dependencies : 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).repositories : Liste des emplacements où le code source est hébergé

Pour l'utilisation d'autres champs, veuillez vous référer au package NPM. Description .json

4.3 Fonctions communes NPM

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

4.3.1 Installation du package NPM

Il existe deux types d'installation du package 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 utilise 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-cli3) .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ésinstallez le package 5).npm list : Vérifiez quels packages sont installés 6).npm submit  : Publier les packages

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!