Depuis sa création, personne n'a jamais considéré JavaScript comme un langage de programmation. Dans l'ère Web 1.0, ce langage de script a été principalement utilisé pour la vérification des formulaires et les effets spéciaux de la page Web. Ce n'est que lorsque l'ère Web 2.0 que les ingénieurs frontaux l'ont utilisé pour améliorer considérablement l'expérience utilisateur sur la page Web que JS était largement appréciée. À mesure que JS devient de plus en plus populaire, il subit à peu près les modifications de la bibliothèque d'outils, de la bibliothèque de composants, du cadre frontal et des applications frontales. JavaScript manque intrinsèquement une fonctionnalité: les modules, et l'émergence de la spécification CommonJs compense cette lacune. Cet article introduira le mécanisme de spécification CommonJS et de module de nœud.
Dans d'autres langages de haut niveau, Java a des fichiers de classe, Python a un mécanisme d'importation et PHP a inclus et requise. La façon dont JS introduit le code via la balise <cript> semble désordonnée. Dans le passé, les gens devaient utiliser des espaces de noms et d'autres méthodes pour contraindre artificiellement le code. Ce n'est que lorsque la spécification CommonJS a émergé que JavaScript frontal et back-end a pu réaliser une grande unité. Node emprunte la spécification des modules de CommonJS pour implémenter un système de module 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 requise () et transmettant un identifiant de module, tel que var math = require ('math');
2) Définition du module: Exporter les méthodes ou variables du module actuel via l'objet Exportations. Il existe également un objet de module dans le module, et les exportations sont en fait l'attribut du module. Dans Node, un fichier est un module et les "variables globales" dans le module sont invisibles pour le monde extérieur. Seuls les attributs montés sur les exportations sont publics, tels que exports.add = function () {}; exports.pi = 3,1415926;
3) ID du module: c'est en fait le paramètre passé pour exiger (). Par exemple, les «mathématiques» mentionnés ci-dessus, ce doit être une chaîne qui est conforme à la nomenclature de chameau, ou un chemin relatif ou absolu en commençant par "." ".." Il ne peut pas avoir de suffixe de nom de fichier ".js"
2. Processus d'implémentation 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 le nœud lui-même, et l'autre est le module de fichier écrit par l'utilisateur lui-même. Certains des modules de base sont compilés en fichiers binaires lors de la compilation du code source de nœud. Lorsque le nœud démarre, le module de noyau est directement chargé dans la mémoire, donc sa vitesse de chargement est la plus rapide. Le module de fichier est chargé dynamiquement au moment de l'exécution et nécessite trois étapes: analyse de chemin, emplacement du fichier et compilation et exécution. Notez que les caches de nœud ont introduit des modules pour réduire les frais généraux lors de l'introduction secondaire et adopte la stratégie la plus préférée pour le chargement secondaire du même module.
2.1 Analyse de chemin
L'analyse de chemin analyse principalement les identificateurs de modules mentionnés ci-dessus, qui sont principalement divisés en catégories suivantes:
1) Modules de base, tels que HTTP, FS, chemin, etc.
2) Module de fichier de chemin relatif à commencer par. ou .
3) Module de fichier de chemin absolu en commençant par /
4) Module de fichier personnalisé, qui peut être sous la forme d'un fichier ou d'un package. Le nœud essaiera de trouver le fichier cible un par un selon le module de chemin de chemin de module.Paths, généralement le long du répertoire actuel étape par étape jusqu'au répertoire racine, à la recherche d'un répertoire nommé node_modules, c'est donc le moyen le plus long pour le trouver.
2.2 Emplacement du fichier
Sur la base de l'analyse du chemin, les détails suivants doivent être prêts à prêter attention à:
1) Analyse d'extension de fichier: Étant donné que la spécification CommonJS permet aux identifiants du module de ne pas être rempli, le nœud essaiera dans l'ordre de .js, .json et .Node.
2) Analyse et package du répertoire: Si aucun fichier correspondant n'est trouvé après l'analyse d'extension de fichier ci-dessus, mais un répertoire est obtenu, le nœud traitera le répertoire comme un package.
2.3 Compilation et exécution
Après avoir localisé le fichier spécifique, le nœud créera un nouvel objet de module, chargera et compile en fonction du chemin. Pour différentes extensions, la méthode de chargement est différente:
1) Fichier .js: Lisez le fichier de manière synchrone via le module FS et compilez et exécutez-le
2). Fichier.
3) Fichier .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: ils sont chargés sous forme de fichiers .js
Nous savons que chaque fichier de module a trois variables: exiger, exportations et module par défaut. Même dans le document API Node, nous savons que chaque module a également deux variables: nom de fichier et dirname. D'où viennent-ils? Comment le module de nœud réalise-t-il que les «variables globales» déclarées ne pollueront pas réellement d'autres modules? En fait, le nœud enveloppera le contenu du fichier au début et se termine lors de la compilation du module JS. Voici un exemple de fichier JS enveloppé par la tête et la queue:
La copie de code est la suivante:
(fonction (exportations, require, module, __filename, __dirname) {
/ * Le milieu est le contenu réel du fichier js * /
var math = require ('math');
export.area = fonction (rayon) {
RETOUR MATH.PI * RADIUS * RADIUS;
};
/ * Le contenu réel du fichier JS se termine * /
});
De cette façon, chaque fichier de module est l'isolement dans la portée et les variables telles que l'exigence, les exportations, les modules, etc. sont également injectées dans le contexte du module. Il s'agit de l'implémentation de la spécification du module CommonJS de Node. Le processus de compilation du module C / C ++ et du module de noyau de nœud est relativement compliqué, donc je ne le répéterai plus.
3. pile d'appels du module
Il est nécessaire de clarifier les relations d'appel de divers modules dans le nœud, comme indiqué dans la figure ci-dessous:
Le module intégré de C / C ++ est le module de niveau le plus bas et appartient au module de base. Il fournit principalement des API pour appeler les modules de base JavaScript et les modules de fichiers JavaScript tiers. En fait, il n'y a presque aucun contact avec de tels modules. Il existe deux principales responsabilités des modules de noyau JavaScript: l'une consiste à servir de couche d'encapsulation et de couche de pontage du module intégré de C / C ++ pour les appels de module de fichier, et l'autre est un module fonctionnel pur qui n'a pas besoin de traiter la couche sous-jacente. 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. Package et NPM
4.1 Structure du package
Le package est essentiellement un fichier d'archive (généralement .zip ou .tar.gz), qui est décompressé et restauré dans un répertoire après l'installation. La spécification du package CommonJS se compose de deux parties: Structure du package et fichier de description du package. Une structure de package conforme pleinement à la spécification CommonJS doit contenir les fichiers suivants:
1) .package.json: fichier de description du package
2) .bin: le répertoire où les fichiers binaires exécutables sont stockés
3) .Lib: le répertoire où le code JavaScript est stocké
4) .doc: le répertoire où le document est stocké
5) .Test: le répertoire où les cas de test unitaires sont stockés
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, est une partie importante du package et est utilisé pour décrire les informations de vue d'ensemble du package. Tous les comportements des NPM qui seront mentionnés plus loin sont étroitement liés aux champs de ce fichier. Ci-dessous, nous utiliserons le fichier package.json d'un projet bien connu Framework Express comme exemple pour illustrer la signification de certains champs couramment utilisés.
1) .Name: nom du package
2) .Description: introduction du package
3) .Version: le numéro de version doit être conforme au "contrôle de version sémantique", reportez-vous à http://semver.org/
4). DÉPENDENCES: Utilisez la liste des packages sur lesquels le package actuel doit dépendre. Cette propriété est très importante. NPM chargera automatiquement le package dépendante via cette propriété
5) .repositoires: liste des emplacements pour l'hébergement du code source
L'utilisation d'autres champs peut être référée au package NPM.Json Description
4.3 Fonctions communes du NPM
NPM (Node Package Manager), communément appelé Node Package Manager. Sa fonction principale est de gérer les packages de nœuds, notamment: installation, désinstaller, mettre à jour, afficher, rechercher, publier, etc.
4.3.1 Installation du package NPM
Il existe deux types d'installation de packages de nœuds: l'installation locale et l'installation globale. La différence entre les deux est la suivante:
1). Installation locale NPM Install <Package-Name>: Le package sera téléchargé dans le répertoire actuel et ne peut être utilisé que dans le répertoire actuel.
2). Global Installation NPM Install -g <Package-Name>: Le package sera téléchargé sur un répertoire système spécifique, et le package installé peut être utilisé dans tous les répertoires.
4.3.2 Gestion des packages NPM
Ce qui suit est une liste des commandes de gestion des packages couramment utilisées en utilisant Grunt-Cli (outil de ligne de commande Grunt) à titre d'exemple:
1) .NPM Installation: Installez tous les packages déclarés par les champs de dépendances et de dépenses du fichier package.json
2) .NPM Installez [email protected]: Installez la version spécifique de Grunt-Cli
3) .NPM Installez Grunt-Contrib-Copy - Save: Installez Grunt-Contrib-copy et enregistrez la dépendance dans le fichier package.json
4) .NPM Désinstaller Grunt-Cli: Package de désinstallation
5).
6) .NPM Publish <folder>: Publier le package