Node.js中CommonJS模組規格用法總結

Javascript先天就缺乏一項功能：模組，而CommonJS規範的出現則彌補了這個缺陷。 CommonJS規格的出現，前後端的Javascript才得以實現大一統。 Node借鑒了CommonJS的Modules規格實作了一套非常易用的模組系統。

1. CommonJS模組規格

CommonJS的模組規格分為3個部分：

1).模組引用：透過require ()方法並傳入一個模組標識來引入一個模組的API到當前上下文中，如var math = require('math');
2).模組定義：透過exports物件來導出當前模組的方法或變數。模組中還存在一個module對象，exports其實是module的屬性。在Node中，一個檔案就是一個模組，模組內的「全域變數」對外都不可見，只有掛載在exports上的屬性才是公開的，如exports.add = function() {}; exports.PI = 3.1415926;
3).模組標識：實際上就是傳遞給require()的參數，如上述的'math'，它必須是符合camel命名法的字串，或者是以“.”“..”開頭的相對路徑或絕對路徑，它可以沒有檔名後綴「.js」

2. Node模組實作過程

在Node中，模組分為兩類別：一類是Node本身提供的核心模組，另一類是使用者自己寫的檔案模組。核心模組有一部分在Node原始碼的編譯過程中，編譯成了二進位文件，在Node啟動時核心模組就被直接載入進記憶體中，所以它的載入速度是最快的。文件模組則是在運行時動態加載，需要經歷三個步驟：路徑分析，文件定位，編譯執行。請注意，Node對引入過的模組都會進行緩存，以減少二次引入時的開銷，並對相同模組的二次加載都採用最優先從緩存加載的策略。

2.1 路徑分析

路徑分析主要分析上述提到的模組標識符，主要分為以下幾類：

1)、核心模組，如http、fs、path等
2)、.或..開始的相對路徑檔案模組
3)、以/開始的絕對路徑檔案模組
4)、自訂檔案模組，可能是一個文件或包的形式。 Node會根據模組路徑數組module.paths來逐一嘗試查找目標文件，通常是沿著當前目錄逐級向上直到根目錄查找名為node_modules的目錄，所以這是查找最費時的一種方式。

2.2 檔案定位

在路徑分析的基礎上，檔案定位需要注意以下細節：

1)、檔案副檔名分析：由於CommonJS規格允許模組識別不填入副檔名，Node會按.js、.json、.node的順序不足副檔名，依序嘗試
2)、目錄分析和套件：若經過上述檔案副檔名分析後沒有查找到對應文件，卻得到一個目錄，Node會把目錄當做一個包來處理

2.3 編譯執行

定位到具體文件後，Node會新建一個模組對象，根據路徑載入並編譯。對於不同的副檔名，載入方法有所不同：

1)、.js檔：透過fs模組同步讀取檔並編譯執行
2)、.node檔：這是用C /C++編寫的擴充文件，透過dlopen()方法載入
3)、.json檔案：透過fs模組同步讀取文件，用JSON.parse()解析回傳結果
4)、其餘副檔名文件：都被當做.js檔案載入

我們知道每個模組檔案中預設都存在著require、exports、module這3個變量，甚至在Node的API文檔中，我們知道每個模組還有filename、dirname這2個變數的存在，它們是從何而來的呢？ Node的模組又是怎麼做到宣告的「全域變數」其實是不會污染到其他模組的？事實上，Node在編譯JS模組過程中會對檔案內容進行頭尾包裝。下面是一個JS檔案經過頭尾包裝的範例：

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

這樣每個模組檔案之間都進行了作用域隔離，同時require、exports、module等變數也被注入到了模組的上下文當中。這就是Node對CommonJS模組規範的實作。關於C/C++模組及Node核心模組的編譯過程較為複雜，不再贅述。

3. 模組呼叫堆疊

有必要明確Node中各種模組的呼叫關係，如下圖所示：

C/C++內建模區塊是最底層的模組，屬於核心模組，主要提供API給Javascript核心模組和第三方Javascript檔案模組調用，實際上幾乎不會接觸到此類模組。 Javascript核心模組主要職責有兩種：一種是作為C/C++內建模塊的封裝層和橋接層供文件模組調用，另一種是純粹的功能模組，不需要跟底層打交道。文件模組通常由第三方編寫，包括普通Javascript模組和C/C++擴充模組。

4. 套件與NPM

4.1 套件結構

#

套件本質上是一個存檔檔案（一般為.zip或.tar.gz），安裝後解壓縮還原為目錄。 CommonJS的包規格由包結構和包描述文件兩部分組成。一個完全符合CommonJS規範的套件結構應包含以下檔案：

1).package.json：套件描述檔
2).bin：存放可執行二進位檔案的目錄
3). lib：存放Javascript程式碼的目錄
4).doc：存放文件的目錄
5).test：存放單元測試案例的目錄

4.2 套件描述檔

套件描述檔是一個JSON檔案－package.json，位於套件的根目錄下，是套件的重要組成部分，用於描述套件的概況資訊。後面要提到的NPM的所有行為都與這個文件的欄位息息相關。以下將以知名Web框架express專案的package.json檔案為例說明一些常用欄位的意義。

1).name：套件名稱
2).description：套件簡介
3).version：版本號，需遵循“語義化的版本控制”，參考http://semver .org/
4).dependencies：使用目前套件所需依賴的套件清單。這個屬性十分重要，NPM會透過這個屬性自動載入依賴的套件
5).repositories：託管原始碼的位置清單

其餘欄位的用法可以參考NPM package.json說明

#4.3 NPM常用功能

NPM（node package manager），通常稱為node套件管理器。它的主要功能是管理node包，包括：安裝、解除安裝、更新、檢視、搜尋、發布等。

4.3.1 NPM套件安裝

Node套件的安裝分成兩種：本機安裝、全域安裝。兩者的差異如下：

1).本機安裝npm install 232e112a1ffb9f21e3b1b7ffee4c43c2：package會被下載到目前所在目錄，也只能在目前目錄下使用。
2).全域安裝npm install -g 232e112a1ffb9f21e3b1b7ffee4c43c2：package會被下載到到特定的系統目錄下，安裝的package能夠在所有目錄下使用。

4.3.2 NPM套件管理

下面以grunt-cli（grunt命令列工具）為例，列出常用的套件管理命令：

1).npm install：安裝package.json檔案的dependencies和devDependencies欄位宣告的所有套件
2).npm install grunt-cli@0.1.9：安裝特定版本的grunt-cli
3) .npm install grunt-contrib-copy --save：安裝grunt-contrib-copy，同時保存該依賴到package.json檔案
4).npm uninstall grunt-cli：卸載套件
5).npm list ：查看安裝了哪些套件
6).npm publish 59ef88518edd60e9f6a2c9f2c966ac0c：發布套件

以上是Node.js中CommonJS模組規格用法總結的詳細內容。更多資訊請關注PHP中文網其他相關文章！