Zusammenfassung der Verwendung der CommonJS-Modulspezifikation in Node.js

Javascript fehlt von Natur aus eine Funktion: Module, und die Entstehung der CommonJS-Spezifikation gleicht diesen Mangel aus. Mit dem Aufkommen der CommonJS-Spezifikation können 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). require ()-Methode und übergeben Sie einen Modulbezeichner, um die API eines Moduls in den aktuellen Kontext einzuführen, z. B. var math = require('math');
2 Moduldefinition: Exportieren Sie die Methoden des aktuellen Moduls über die Exportiert ein Objekt oder eine Variable. 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 Kamel-Nomenklatur entspricht oder mit „.“ beginnt ..“ Der relative Pfad oder der absolute Pfad am Anfang, er darf nicht das Dateinamensuffix „.js“ haben

2. Knotenmodul-Implementierungsprozess

In Node, das Modul ist in zwei Klassen unterteilt: Ein Typ ist das von Node selbst bereitgestellte Kernmodul und der andere Typ 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), Kern Module wie http, fs, path usw.
2), relative Pfaddateimodule beginnend mit oder ..
3), absolute Pfaddateimodule beginnend mit /
4), benutzerdefinierte Dateimodule , Kann in Form einer Datei oder eines Pakets vorliegen. 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 Dateispeicherort

Basierend auf der Pfadanalyse muss der Dateispeicherort auf die folgenden Details achten:

1), Dateierweiterungsanalyse: Aufgrund der CommonJS-Spezifikation darf die Modulkennung die Erweiterung nicht in der Reihenfolge .js, .json und .node ausfüllen und versucht
2), Verzeichnisanalyse und Paket in der Reihenfolge : Wenn nach der obigen Dateierweiterungsanalyse keine Suche nach der entsprechenden Datei gefunden wird, aber ein Verzeichnis erhalten wird, behandelt Node das Verzeichnis als Paket

2.3 Kompilieren und ausführen

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 sind die Lademethoden unterschiedlich:

1), .js-Datei: Lesen Sie die Datei synchron über das fs-Modul und kompilieren und führen Sie
2), .node-Datei: Dies verwendet C / In C++ geschriebene Erweiterungsdateien werden über die dlopen()-Methode geladen
3), .json-Dateien: Lesen Sie die Datei synchron über das fs-Modul und verwenden Sie JSON.parse(), um das Ergebnis zu analysieren und zurückzugeben
4) , und 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 über drei Variablen verfügt Es gibt zwei Variablen, Dateiname und Verzeichnisname. Woher kommen sie? 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 für eine JS-Datei mit Head- und Tail-Verpackung:

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

Auf diese Weise verfügt jede Moduldatei über eine Bereichsisolierung, und Variablen wie „require“, „exports“ und „module“ werden ebenfalls in die Datei eingefügt Kontext des Moduls unter. Dies ist Nodes Implementierung der CommonJS-Modulspezifikation. Der Kompilierungsprozess von C/C++-Modulen und Node-Core-Modulen 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 Abbildung unten gezeigt:

Das integrierte C/C++-Modul ist das unterste Modul und ein Kernmodul. Es stellt hauptsächlich APIs für den Aufruf von Javascript-Kernmodulen und Javascript-Dateimodulen von Drittanbietern bereit Module werden fast nie freigelegt. Das Javascript-Kernmodul hat zwei Hauptaufgaben: Die eine besteht darin, als Kapselungsschicht und Überbrückungsschicht der in C/C++ integrierten Module für Dateimodulaufrufe zu dienen, und die andere ist ein rein funktionales Modul, das sich nicht mit der Unterseite befassen muss 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 CommonJS-Paketspezifikation besteht aus zwei Teilen: Paketstruktur und 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, muss der „semantischen Versionskontrolle“ entsprechen, siehe http:// semver .org/
4).dependencies: 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 im NPM-Paket .json-Beschreibung

4.3 Allgemeine NPM-Funktionen

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

4.3.1 NPM-Paketinstallation

Es gibt zwei Arten der Knotenpaketinstallation: lokale Installation und globale Installation. Der Unterschied zwischen den beiden ist wie folgt:

1). Lokale Installation npm install cda4cf10c497d73c86c3def2a7bd2dd9: Das Paket wird in das aktuelle Verzeichnis heruntergeladen und kann nur im aktuellen Verzeichnis verwendet werden.
2) Globale Installation npm install -g cda4cf10c497d73c86c3def2a7bd2dd9: 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: Installiert eine bestimmte Version von grunt-cli
3) .npm install grunt-contrib-copy --save: Installiere grunt-contrib-copy und speichere die Abhängigkeit in der package.json-Datei
4).npm uninstall grunt-cli: Deinstalliere das Paket
5).npm-Liste: Überprüfen Sie, welche Pakete installiert sind
6).npm-Veröffentlichung

Das obige ist der detaillierte Inhalt vonZusammenfassung der Verwendung der CommonJS-Modulspezifikation in Node.js. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!