Studienhinweise zum Modulmechanismus in Node.js_node.js

Seit der Geburt von Javascript hat es niemand mehr als Programmiersprache betrachtet. In der Web 1.0-Ära wurde diese Skriptsprache hauptsächlich zur Formularvalidierung und für Spezialeffekte auf Webseiten verwendet. Erst in der Web 2.0-Ära, als Front-End-Ingenieure es nutzten, um das Benutzererlebnis auf Webseiten erheblich zu verbessern, erlangte JS große Anerkennung. Da JS immer beliebter wird, hat es grobe Änderungen in Werkzeugbibliotheken, Komponentenbibliotheken, Front-End-Frameworks und Front-End-Anwendungen erfahren. Javascript fehlt von Natur aus eine Funktion: Module, und die Entstehung der CommonJS-Spezifikation gleicht dieses Manko aus. In diesem Artikel werden die CommonJS-Spezifikation und der Modulmechanismus von Node vorgestellt.

Neben anderen Hochsprachen verfügt Java über Klassendateien, Python über einen Importmechanismus und PHP über include und require. Die Art und Weise, wie JS Code über das -Tag einführt, erscheint chaotisch. In der Vergangenheit mussten Benutzer Namespaces und andere Methoden verwenden, um den Code künstlich einzuschränken. Erst mit der Einführung der CommonJS-Spezifikation konnten Front-End- und Back-End-Javascript vereinheitlicht werden. Node greift auf die Modules-Spezifikation von CommonJS zurück, um ein sehr benutzerfreundliches Modulsystem zu implementieren.

1. CommonJS-Modulspezifikation

Die Modulspezifikation von CommonJS ist in 3 Teile unterteilt:

1). Modulreferenz: Führen Sie die API eines Moduls über die Methode require() ein und übergeben Sie einen Modulbezeichner, z. B. var math = require('math'); 2).Moduldefinition: Exportieren Sie die Methoden oder Variablen des aktuellen Moduls über das Exportobjekt. Es gibt auch ein Modulobjekt im Modul, und Exporte sind tatsächlich Attribute des Moduls. In Node ist eine Datei ein Modul und die „globalen Variablen“ innerhalb des Moduls sind für die Außenwelt nicht sichtbar. Nur die auf Exports gemounteten Attribute sind öffentlich, wie etwa exports.add = function() {}; = 3,1415926; 3) Modulidentifikation: Es handelt sich tatsächlich um den an require() übergebenen Parameter, z. B. den obigen „math“, der eine Zeichenfolge sein muss, die der Camel-Nomenklatur entspricht, oder ein relativer Pfad, der mit „..“ beginnt. oder Absoluter Pfad, es darf kein Dateinamensuffix „.js“ haben

2. Knotenmodul-Implementierungsprozess

In Node sind Module in zwei Kategorien unterteilt: Eines ist das von Node selbst bereitgestellte Kernmodul und das andere ist das vom Benutzer geschriebene Dateimodul. Ein Teil des Kernmoduls wird während des Kompilierungsprozesses des Node-Quellcodes in eine Binärdatei kompiliert. Das Kernmodul wird beim Start von Node direkt in den Speicher geladen, sodass seine Ladegeschwindigkeit am schnellsten ist. Das Dateimodul wird zur Laufzeit dynamisch geladen und erfordert drei Schritte: Pfadanalyse, Dateispeicherort sowie Kompilierung und Ausführung. Beachten Sie, dass Node importierte Module zwischenspeichert, um die Kosten für die sekundäre Einführung zu reduzieren, und die Strategie des Ladens aus dem Cache mit der höchsten Priorität für das sekundäre Laden desselben Moduls anwendet.

2.1 Pfadanalyse

Die Pfadanalyse analysiert hauptsächlich die oben genannten Modulkennungen, die hauptsächlich in die folgenden Kategorien unterteilt sind:

1), Kernmodule wie http, fs, path usw. 2) Dateimodul mit relativem Pfad, beginnend mit .. oder .. 3). Absoluter Pfad-Dateimodul, beginnend mit / 4) Benutzerdefiniertes Dateimodul, das in Form einer Datei oder eines Pakets vorliegen kann. Node versucht, die Zieldatei nacheinander anhand des Modulpfad-Arrays module.paths zu finden. Normalerweise wird das Verzeichnis mit dem Namen node_modules Schritt für Schritt entlang des aktuellen Verzeichnisses bis zum Stammverzeichnis durchsucht, daher ist dies die zeitaufwändigste Methode um es zu finden.

2.2 Dateipositionierung

Basierend auf der Pfadanalyse muss beim Dateispeicherort auf die folgenden Details geachtet werden:

1) Dateierweiterungsanalyse: Da die CommonJS-Spezifikation zulässt, dass die Modulkennung die Erweiterung nicht ausfüllt, füllt Node die Erweiterung in der Reihenfolge .js, .json und .node aus und versucht es der Reihe nach 2) Verzeichnisanalyse und Pakete: Wenn die entsprechende Datei nach der obigen Dateierweiterungsanalyse nicht gefunden wird, aber ein Verzeichnis erhalten wird, behandelt Node das Verzeichnis als Paket

2.3 Zusammenstellung und Ausführung

Nachdem Node die spezifische Datei gefunden hat, erstellt er ein neues Modulobjekt, lädt es und kompiliert es entsprechend dem Pfad. Für verschiedene Erweiterungen ist die Lademethode unterschiedlich:

1), .js-Datei: Lesen Sie die Datei synchron über das fs-Modul und kompilieren und führen Sie aus 2). .node-Datei: Dies ist eine in C/C geschriebene und über die dlopen()-Methode geladene Erweiterungsdatei 3).json-Datei: Lesen Sie die Datei synchron über das fs-Modul und verwenden Sie JSON.parse(), um das Ergebnis zu analysieren und zurückzugeben 4) Andere Erweiterungsdateien: werden als .js-Dateien geladen

Wir wissen, dass jede Moduldatei standardmäßig drei Variablen hat: „require“, „exports“ und „module“. Selbst in der API-Dokumentation von Node wissen wir, dass jedes Modul auch zwei Variablen hat: „filename“ und „dirname“. Wie stellt das Node-Modul sicher, dass die deklarierten „globalen Variablen“ andere Module nicht tatsächlich kontaminieren? Tatsächlich umschließt Node den Dateiinhalt während der Kompilierung von JS-Modulen mit Kopf und Ende. Das Folgende ist ein Beispiel einer JS-Datei mit Head- und Tail-Verpackung:

Code kopieren Der Code lautet wie folgt: (function(exports, require, module, __filename, __dirname) { /* Die Mitte ist der eigentliche Inhalt der JS-Datei */ var math = require('math'); exports.area = function(radius) { return Math.PI * radius * radius; }; /* Der eigentliche Inhalt der JS-Datei endet */ }); Auf diese Weise ist jede Moduldatei bereichsisoliert und Variablen wie „require“, „exports“ und „module“ werden auch in den Kontext des Moduls eingefügt. Dies ist Nodes Implementierung der CommonJS-Modulspezifikation. Der Kompilierungsprozess von C/C-Modulen und Node-Kernmodulen ist relativ kompliziert und wird nicht im Detail beschrieben.

3. Modulaufrufstapel

Es ist notwendig, die Aufrufbeziehung verschiedener Module in Node zu klären, wie in der folgenden Abbildung dargestellt:

Das integrierte C/C-Modul ist das niedrigste Modul und ein Kernmodul. Es stellt hauptsächlich APIs für den Aufruf von Javascript-Kernmodulen und Javascript-Dateimodulen von Drittanbietern bereit. Das Javascript-Kernmodul hat zwei Hauptaufgaben: Zum einen dient es als Kapselungsschicht und Überbrückungsschicht des in C/C integrierten Moduls für Dateimodulaufrufe, zum anderen ist es ein rein funktionales Modul, das sich nicht mit dem befassen muss untere Schicht. Dateimodule werden normalerweise von Dritten geschrieben, einschließlich gewöhnlicher Javascript-Module und C/C-Erweiterungsmodule.

4. Pakete und NPM

4.1 Paketstruktur

Ein Paket ist im Wesentlichen eine Archivdatei (normalerweise .zip oder .tar.gz), die nach der Installation dekomprimiert und in einem Verzeichnis wiederhergestellt werden kann. Die Paketspezifikation von CommonJS besteht aus zwei Teilen: der Paketstruktur und der Paketbeschreibungsdatei. Eine Paketstruktur, die vollständig der CommonJS-Spezifikation entspricht, sollte die folgenden Dateien enthalten:

1).package.json: Paketbeschreibungsdatei 2).bin: Verzeichnis, in dem ausführbare Binärdateien gespeichert sind 3).lib: Verzeichnis zum Speichern von Javascript-Code 4).doc: Verzeichnis zum Speichern von Dokumenten 5).test: Verzeichnis zum Speichern von Unit-Testfällen

4.2 Paketbeschreibungsdatei

Die Paketbeschreibungsdatei ist eine JSON-Datei – package.json, die sich im Stammverzeichnis des Pakets befindet. Sie ist ein wichtiger Teil des Pakets und wird zur Beschreibung der allgemeinen Informationen des Pakets verwendet. Alle später erwähnten Verhaltensweisen von NPM stehen in engem Zusammenhang mit den Feldern dieser Datei. Im Folgenden wird die Datei package.json des bekannten Web-Framework-Express-Projekts als Beispiel verwendet, um die Bedeutung einiger allgemeiner Felder zu veranschaulichen.

1).name: Paketname 2).Beschreibung: Paketeinführung 3).version: Versionsnummer, die der „semantischen Versionskontrolle“ entsprechen muss, siehe http://semver.org/ 4).Abhängigkeiten: Liste der Pakete, die zur Verwendung des aktuellen Pakets erforderlich sind. Dieses Attribut ist sehr wichtig. NPM lädt abhängige Pakete automatisch über dieses Attribut 5).repositories: Liste der Orte, an denen der Quellcode gehostet wird

Informationen zur Verwendung anderer Felder finden Sie in der Beschreibung von NPM package.json

4.3 Allgemeine NPM-Funktionen

NPM (Knotenpaketmanager), normalerweise Knotenpaketmanager genannt. Seine Hauptfunktion besteht darin, Knotenpakete zu verwalten, einschließlich: Installation, Deinstallation, Aktualisierung, Anzeige, Suche, Freigabe usw.

4.3.1 NPM-Paketinstallation

Es gibt zwei Arten der Installation von Node-Paketen: lokale Installation und globale Installation. Der Unterschied zwischen den beiden ist wie folgt:

1). Lokale Installation npm install : Das Paket wird in das aktuelle Verzeichnis heruntergeladen und kann nur im aktuellen Verzeichnis verwendet werden. 2) Globale Installation npm install -g : Das Paket wird in ein bestimmtes Systemverzeichnis heruntergeladen und das installierte Paket kann in allen Verzeichnissen verwendet werden.

4.3.2 NPM-Paketverwaltung

Im Folgenden wird grunt-cli (Grunt-Befehlszeilentool) als Beispiel verwendet, um häufig verwendete Paketverwaltungsbefehle aufzulisten:

1).npm install: Installiert alle Pakete, die in den Feldern dependencies und devDependencies der package.json-Datei deklariert sind 2).npm install grunt-cli@0.1.9: Installieren Sie eine bestimmte Version von grunt-cli 3).npm install grunt-contrib-copy --save: Installieren Sie grunt-contrib-copy und speichern Sie die Abhängigkeit in der package.json-Datei 4).npm uninstall grunt-cli: Paket deinstallieren 5).npm-Liste: Überprüfen Sie, welche Pakete installiert sind 6).npm veröffentlichen : Paket veröffentlichen