詳解NodeJS模塊化

Posted on 2021-06-15 by WalkonNet

一、前言

我們知道，Node.js是基於CommonJS規范進行模塊化管理的，模塊化是面對復雜的業務場景不可或缺的工具，或許你經常使用它，但卻從沒有系統的瞭解過，所以今天我們來聊一聊Node.js模塊化你所需要知道的一些事兒，一探Node.js模塊化的面貌。

二、正文

在Node.js中，內置瞭兩個模塊來進行模塊化管理，這兩個模塊也是兩個我們非常熟悉的關鍵字：require和module。內置意味著我們可以在全局范圍內使用這兩個模塊，而無需像其他模塊一樣，需要先引用再使用。

無需 require(‘require’) or require(‘module’)

在Node.js中引用一個模塊並不是什麼難事兒，很簡單：

const config = require('/path/to/file')

但實際上，這句簡單的代碼執行瞭一共五個步驟：

瞭解這五個步驟有助於我們瞭解Node.js模塊化的基本原理，也能讓我們甄別一些陷阱，讓我們簡單概括下這五個步驟都做瞭什麼：

Resolving：找到待引用的目標模塊，並生成絕對路徑。
Loading：判斷待引用的模塊內容是什麼類型，它可能是.json文件、.js文件或者.node文件。
Wrapping：顧名思義，包裝被引用的模塊。通過包裝，讓模塊具有私有作用域。
Evaluating：被加載的模塊被真正的解析和處理執行。
Caching：緩存模塊，這讓我們在引入相同模塊時，不用再重復上述步驟。

有些同學看完這五個步驟可能已經心知肚明，對這些原理輕車熟路，有些同學心中可能產生瞭更多疑惑，無論如何，接下來的內容會詳細解析上述的執行步驟，希望能幫助大傢答疑解惑 or 鞏固知識、查缺補漏。

By the way，如果有需要，可以和我一樣，構建一個實驗目錄，跟著Demo進行實驗。

2.1、什麼是模塊

想要瞭解模塊化，需要先直觀地看看模塊是什麼。

我們知道在Node.js中，文件即模塊，剛剛提到瞭模塊可以是.js、.json或者.node文件，通過引用它們，可以獲取工具函數、變量、配置等等，但是它的具體結構是怎樣呢？在命令行中簡單執行下面的命令就可以看到模塊，也就是module對象的結構：

~/learn-node $ node

> module

Module {

id: ‘<repl>’,

exports: {},

parent: undefined,

filename: null,

loaded: false,

children: [],

paths: [ … ] }

可以看到模塊也就是一個普通對象，隻不過結構中有幾個特殊的屬性值，需要我們一一去理解，有些屬性，例如id、parent、filename、children甚至都無需解釋，通過字面意思就可以理解。

後續的內容會幫助大傢理解這些字段的意義和作用。

2.2、Resolving

大致瞭解瞭什麼是模塊後，我們從第一個步驟Resolving開始，瞭解模塊化原理，也就是Node.js如何尋找目標模塊，並生成目標模塊的絕對路徑。

那麼什麼我們剛剛要先打印module對象，先讓大傢瞭解module的結構呢？因為這裡有兩個字段值id、paths和Resolving這個步驟息息相關。一起來看看吧。

首先是 id 屬性：

每個module都有id屬性，通常這個屬性值是模塊的完整路徑，通過這個值Node.js可以標識和定位模塊的所在位置。但是在這兒並沒有具體的模塊，我們隻是在命令行中輸出瞭module的結構，所以為默認的<repl>值（repl表示交互式解釋器）。

其次是paths屬性：

這個paths屬性有什麼作用呢？Node.js允許我們用多種方式來引用模塊，比如相對路徑、絕對路徑、預置路徑（馬上會解釋），假設我們需要引用一個叫做find-me的模塊，require如何幫助我們找到這個模塊呢？

require('find-me')

我們先打印看看paths中是什麼內容：

~/learn-node $ node
> module.paths
[ '/Users/samer/learn-node/repl/node_modules',
  '/Users/samer/learn-node/node_modules',
  '/Users/samer/node_modules',
  '/Users/node_modules',
  '/node_modules',
  '/Users/samer/.node_modules',
  '/Users/samer/.node_libraries',
  '/usr/local/Cellar/node/7.7.1/lib/node' ]

ok，其實就是一堆系統絕對路徑，這些路徑表示瞭所有目標模塊可能出現的位置，並且它們是有序的，這意味著Node.js會按序查找paths中列出的所有路徑，如果找到這個模塊，就輸出該模塊的絕對路徑供後續使用。

現在我們知道Node.js會在這一堆目錄中查找module，嘗試執行require(‘find-me’)來查找find-me模塊，由於我們並沒有在任何目錄放置find-me模塊，所以Node.js在遍歷所有目錄之後並不能找到目標模塊，因此報錯Cannot find module ‘find-me’，這個錯誤大傢也許經常看到：

~/learn-node $ node

> require(‘find-me’)

Error: Cannot find module ‘find-me’

at Function.Module._resolveFilename (module.js:470:15)

at Function.Module._load (module.js:418:25)

at Module.require (module.js:498:17)

at require (internal/module.js:20:19)

at repl:1:1

at ContextifyScript.Script.runInThisContext (vm.js:23:33)

at REPLServer.defaultEval (repl.js:336:29)

at bound (domain.js:280:14)

at REPLServer.runBound [as eval] (domain.js:293:12)

at REPLServer.onLine (repl.js:533:10)

現在，可以嘗試把需要引用的find-me模塊放在上述的任意一個目錄下，在這裡我們創建一個node_modules目錄，並創建find-me.js文件，讓Node.js能夠找到它：

~/learn-node $ mkdir node_modules

~/learn-node $ echo “console.log(‘I am not lost’);” > node_modules/find-me.js

~/learn-node $ node

> require(‘find-me’);

I am not lost

{}

>

手動創建瞭find-me.js文件後，Node.js果然找到瞭目標模塊。當然，當Node.js本地的node_modules目錄中找到瞭find-me模塊，就不會再去後續的目錄中繼續尋找瞭。

有Node.js開發經驗的同學會發現在引用模塊時，不一定非得指定到準確的文件，也可以通過引用目錄來完成對目標模塊的引用，例如：

~/learn-node $ mkdir -p node_modules/find-me

~/learn-node $ echo “console.log(‘Found again.’);” > node_modules/find-me/index.js

~/learn-node $ node

> require(‘find-me’);

Found again.

{}

>

find-me目錄下的index.js文件會被自動引入。

當然，這是有規則限制的，Node.js之所以能夠找到find-me目錄下的index.js文件，是因為默認的模塊引入規則是當具體的文件名缺失時尋找index.js文件。我們也可以更改引入規則(通過修改package.json），比如把index -> main:

~/learn-node $ echo “console.log(‘I rule’);” > node_modules/find-me/main.js

~/learn-node $ echo ‘{ “name”: “find-me-folder”, “main”: “main.js” }’ > node_modules/find-me/package.json

~/learn-node $ node

> require(‘find-me’);

I rule

{}

>

2.3、require.resolve

如果你隻想要在項目中引入某個模塊，而不想立即執行它，可以使用require.resolve方法，它和require方法功能相似，隻是並不會執行被引入的模塊方法：

> require.resolve(‘find-me’);

‘/Users/samer/learn-node/node_modules/find-me/start.js’

> require.resolve(‘not-there’);

Error: Cannot find module ‘not-there’

at Function.Module._resolveFilename (module.js:470:15)

at Function.resolve (internal/module.js:27:19)

at repl:1:9

at ContextifyScript.Script.runInThisContext (vm.js:23:33)

at REPLServer.defaultEval (repl.js:336:29)

at bound (domain.js:280:14)

at REPLServer.runBound [as eval] (domain.js:293:12)

at REPLServer.onLine (repl.js:533:10)

at emitOne (events.js:101:20)

at REPLServer.emit (events.js:191:7)

>

可以看到，如果該模塊被找到瞭，Node.js會打印模塊的完整路徑，如果未找到，就報錯。

瞭解瞭Node.js是如何尋找模塊之後，來看看Node.js是如何加載模塊的。

2.4、模塊間的父子依賴關系

我們把模塊間引用關系，表示為父子依賴關系。

簡單創建一個lib/util.js文件，添加一行console.log語句，標識這是一個被引用的子模塊。

~/learn-node $ mkdir lib

~/learn-node $ echo “console.log(‘In util’);” > lib/util.js

在index.js也輸入一行console.log語句，標識這是一個父模塊，並引用剛剛創建的lib/util.js作為子模塊。

~/learn-node $ echo “require(‘./lib/util’); console.log(‘In index, parent’, module);” > index.js

執行index.js，看看它們間的依賴關系：

~/learn-node $ node index.js

In util

In index <ref *1> Module {

id: ‘.’,

path: ‘/Users/samer/’,

exports: {},

parent: null,

filename: ‘/Users/samer/index.js’,

loaded: false,

children: [

Module {

id: ‘/Users/samer/lib/util.js’,

path: ‘/Users/samer/lib’,

exports: {},

parent: [Circular *1],

filename: ‘/Users/samer/lib/util.js’,

loaded: true,

children: [],

paths: [Array]

}

],

paths: […]

}

在這裡我們關註與依賴關系相關的兩個屬性：children和parent。

在打印的結果中，children字段包含瞭被引入的util.js模塊，這表明瞭util.js是index.js所依賴的子模塊。

但仔細觀察util.js模塊的parent屬性，發現這裡出現瞭Circular這個值，原因是當我們打印模塊信息時，產生瞭循環的依賴關系，在子模塊信息中打印父模塊信息，又要在父模塊信息中打印子模塊信息，所以Node.js簡單地將它處理標記為Circular。

為什麼需要瞭解父子依賴關系呢？因為這關系到Node.js是如何處理循環依賴關系的，後續會詳細描述。

在看循環依賴關系的處理問題之前，我們需要先瞭解兩個關鍵的概念：exports和module.exports。

2.5、exports, module.exports

exports：

exports是一個特殊的對象，它在Node.js中可以無需聲明，作為全局變量直接使用。它實際上是module.exports的引用，通過修改exports可以達到修改module.exports的目的。

exports也是剛剛打印的module結構中的一個屬性值，但是剛剛打印出來的值都是空對象，因為我們並沒有在文件中對它進行操作，現在我們可以嘗試簡單地為它賦值：

// 在lib/util.js的開頭新增一行
exports.id = 'lib/util';
  
// 在index.js的開頭新增一行
exports.id = 'index';

執行index.js：

~/learn-node $ node index.js

In index Module {

id: ‘.’,

exports: { id: ‘index’ },

loaded: false,

… }

In util Module {

id: ‘/Users/samer/learn-node/lib/util.js’,

exports: { id: ‘lib/util’ },

parent:

Module {

id: ‘.’,

exports: { id: ‘index’ },

loaded: false,

… },

loaded: false,

… }

可以看到剛剛添加的兩個id屬性被成功添加到exports對象中。我們也可以添加除id以外的任意屬性，就像操作普通對象一樣，當然也可以把exports變成一個function，例如：

exports = function() {}

module.exports:

module.exports對象其實就是我們最終通過require所得到的東西。我們在編寫一個模塊時，最終給module.exports賦什麼值，其他人引用該模塊時就能得到什麼值。例如，結合剛剛對lib/util的操作：

const util = require('./lib/util');
  
console.log('UTIL:', util);
  
// 輸出結果
  
UTIL: { id: 'lib/util' }

由於我們剛剛通過exports對象為module.exports賦值{id: ‘lib/util’}，因此require的結果就相應地發生瞭變化。

現在我們大致瞭解瞭exports和module.exports都是什麼，但是有一個小細節需要註意，那就是Node.js的模塊加載是個同步的過程。

我們回過頭來看看module結構中的loaded屬性，這個屬性標識這個模塊是否被加載完成，通過這個屬性就能簡單驗證Node.js模塊加載的同步性。

當模塊被加載完成後，loaded值應該為true。但到目前為止每次我們打印module時，它的狀態都是false，這其實正是因為在Node.js中，模塊的加載是同步的，當我們還未完成加載的動作（加載的動作包括對module進行標記，包括標記loaded屬性），因此打印出的結果就是默認的loaded: false。

我們用setImmediate來幫助我們驗證這個信息：

// In index.js
setImmediate(() => {
  console.log('The index.js module object is now loaded!', module)
});
點擊並拖拽以移動
The index.js module object is now loaded! Module {
  id: '.',
  exports: [Function],
  parent: null,
  filename: '/Users/samer/learn-node/index.js',
  loaded: true,
  children:
   [ Module {
       id: '/Users/samer/learn-node/lib/util.js',
       exports: [Object],
       parent: [Circular],
       filename: '/Users/samer/learn-node/lib/util.js',
       loaded: true,
       children: [],
       paths: [Object] } ],
  paths:
   [ '/Users/samer/learn-node/node_modules',
     '/Users/samer/node_modules',
     '/Users/node_modules',
     '/node_modules' ] }

ok，由於console.log被後置到加載完成（打完標記）之後，因此現在加載狀態變成瞭loaded: true。這充分驗證瞭Node.js模塊加載是一個同步過程。

瞭解瞭exports、module.exports以及模塊加載的同步性後，來看看Node.js是如何處理模塊的循環依賴關系。

2.6、模塊循環依賴

在上述內容中，我們瞭解到瞭模塊之間是存在父子依賴關系的，那如果模塊之間產生瞭循環的依賴關系，Node.js會怎麼處理呢？假設有兩個模塊，分別為module1.js和modole2.js，並且它們互相引用瞭對方，如下：

// lib/module1.js
  
exports.a = 1;
  
require('./module2'); // 在這兒引用
  
exports.b = 2;
exports.c = 3;
  
// lib/module2.js
  
const Module1 = require('./module1');
console.log('Module1 is partially loaded here', Module1); // 引用module1並打印它

嘗試運行module1.js，可以看到輸出結果：

~/learn-node $ node lib/module1.js

Module1 is partially loaded here { a: 1 }

結果中隻輸出瞭{a: 1}，而{b: 2, c: 3}卻不見瞭。仔細觀察module1.js，發現我們在module1.js的中間位置添加瞭對module2.js的引用，也就是exports.b = 2和exports.c = 3還未執行之前的位置。如果我們把這個位置稱作發生循環依賴的位置，那麼我們得到的結果就是在循環依賴發生前被導出的屬性，這也是基於我們上述驗證過的Node.js的模塊加載是同步過程的結論。

Node.js就是這樣簡單地處理循環依賴。在加載模塊的過程中，會逐步構建exports對象，為exports賦值。如果我們在模塊被完全加載前就引用這個模塊，那麼我們隻能得到部分的exports對象屬性。

2.7、.json和.node

在Node.js中，我們不僅能用require來引用JavaScript文件，還能用於引用JSON或C++插件（.json和.node文件）。我們甚至都不需要顯式地聲明對應的文件後綴。

在命令行中也可以看到require所支持的文件類型：

~ % node

> require.extensions

[Object: null prototype] {

‘.js’: [Function (anonymous)],

‘.json’: [Function (anonymous)],

‘.node’: [Function (anonymous)]

}

當我們用require引用一個模塊，首先Node.js會去匹配是否有.js文件，如果沒有找到，再去匹配.json文件，如果還沒找到，最後再嘗試匹配.node文件。但是通常情況下，為瞭避免混淆和引用意圖不明，可以遵循在引用.json或.node文件時顯式地指定後綴，引用.js時省略後綴（可選，或都加上後綴）。

.json文件:

引用.json文件很常用，例如一些項目中的靜態配置，使用.json文件來存儲更便於管理，例如：

{
  "host": "localhost",
  "port": 8080
}

引用它或使用它都很簡單：

const { host, port } = require('./config');
console.log(`Server will run at http://${host}:${port}`)

輸出如下：

Server will run at http://localhost:8080

.node文件：

.node文件是由C++文件轉化而來，官網提供瞭一個簡單的由C++實現的hello插件，它暴露瞭一個hello()方法，輸出字符串world。有需要的話，可以跳轉鏈接做更多瞭解並進行實驗。

我們可以通過node-gyp來將.cc文件編譯和構建成.node文件，過程也非常簡單，隻需要配置一個binding.gyp文件即可。這裡不詳細闡述，隻需要知道生成.node文件後，就可以正常地引用該文件，並使用其中的方法。

例如，將hello()轉化生成addon.node文件後，引用並使用它：

const addon = require('./addon');
console.log(addon.hello());

2.8、Wrapping

其實在上述內容中，我們闡述瞭在Node.js中引用一個模塊的前兩個步驟Resolving和Loading，它們分別解決瞭模塊的路徑和加載的問題。接下來看看Wrapping都做瞭什麼。

Wrapping就是包裝，包裝的對象就是所有我們在模塊中寫的代碼。也就是我們引用模塊時，其實經歷瞭一層『透明』的包裝。

要瞭解這個包裝過程，首先要理解exports和module.exports之間的區別。

exports是對module.exports的引用，我們可以在模塊中使用exports來導出屬性，但是不能直接替換它。例如：

exports.id = 42; // ok，此時exports指向module.exports，相當於修改瞭module.exports.
exports = { id: 42 }; // 無用，隻是將它指向瞭{ id: 42 }對象而已，對module.exports不會產生實際改變.
module.exports = { id: 42 }; // ok，直接操作module.exports.

大傢也許會有疑惑，為什麼這個exports對象似乎對每個模塊來說都是一個全局對象，但是它又能夠區分導出的對象是來自於哪個模塊，這是怎麼做到的。

在瞭解包裝(Wrapping)過程之前，來看一個小例子：

// In a.js
var value = 'global'
  
// In b.js
console.log(value)  // 輸出：global
  
// In c.js
console.log(value)  // 輸出：global
  
// In index.html
...
<script src="a.js"></script>
<script src="b.js"></script>
<script src="c.js"></script>

當我們在a.js腳本中定義一個值value，這個值是全局可見的，後續引入的b.js和c.js都是可以訪問該value值。但是在Node.js模塊中卻並不是這樣，在一個模塊中定義的變量具有私有作用域，在其它模塊中無法直接訪問。這個私有作用域如何產生的？

答案很簡單，是因為在編譯模塊之前，Node.js將模塊中的內容包裝在瞭一個function中，通過函數作用域實現瞭私有作用域。

通過require(‘module’).wrapper可以打印出wrapper屬性：

~ $ node

> require(‘module’).wrapper

[ ‘(function (exports, require, module, __filename, __dirname) { ‘,

‘\n});’ ]

>

Node.js不會直接執行文件中的任何代碼，但它會通過這個包裝後的function來執行代碼，這讓我們的每個模塊都有瞭私有作用域，不會互相影響。

這個包裝函數有五個參數：exports, require, module, __filename, __dirname。我們可以通過arguments參數直接訪問和打印這些參數：

/learn-node $ echo “console.log(arguments)” > index.js

~/learn-node $ node index.js

{ ‘0’: {},

‘1’:

{ [Function: require]

resolve: [Function: resolve],

main:

Module {

id: ‘.’,

exports: {},

parent: null,

filename: ‘/Users/samer/index.js’,

loaded: false,

children: [],

paths: [Object] },

extensions: { … },

cache: { ‘/Users/samer/index.js’: [Object] } },

‘2’:

Module {

id: ‘.’,

exports: {},

parent: null,

filename: ‘/Users/samer/index.js’,

loaded: false,

children: [],

paths: [ … ] },

‘3’: ‘/Users/samer/index.js’,

‘4’: ‘/Users/samer’ }

簡單瞭解一下這幾個參數，第一個參數exports初始時為空（未賦值），第二、三個參數require和module是和我們引用的模塊相關的實例，它們倆不是全局的。第四、五個參數__filename和__dirname分別表示瞭文件路徑和目錄。

整個包裝後的函數所做的事兒約等於：

unction (require, module, __filename, __dirname) {
  let exports = module.exports;
    
  // Your Code...
    
  return module.exports;
}

總而言之，wrapping就是將我們的模塊作用域私有化，以module.exports作為返回值將變量或方法暴露出來，以供使用。

2.9、Cache

緩存很容易理解，通過一個案例來看看吧：

echo ‘console.log(`log something.`)’ > index.js

// In node repl

> require(‘./index.js’)

log something.

{}

> require(‘./index.js’)

{}

>

可以看到，兩次引用同一個模塊，隻打印瞭一次信息，這是因為第二次引用時取的是緩存，無需重新加載模塊。

打印require.cache可以看到當前的緩存信息：

> require.cache

[Object: null prototype] {

‘/Users/samer/index.js’: Module {

id: ‘/Users/samer/index.js’,

path: ‘/Users/samer/’,

exports: {},

parent: Module {

id: ‘<repl>’,

path: ‘.’,

exports: {},

parent: undefined,

filename: null,

loaded: false,

children: [Array],

paths: [Array]

},

filename: ‘/Users/samer/index.js’,

loaded: true,

children: [],

paths: [

‘/Users/samer/learn-node/repl/node_modules’,

‘/Users/samer/learn-node/node_modules’,

‘/Users/samer/node_modules’,

‘/Users/node_modules’,

‘/node_modules’,

‘/Users/samer/.node_modules’,

‘/Users/samer/.node_libraries’,

‘/usr/local/Cellar/node/7.7.1/lib/node’

]

}

}

可以看到剛剛引用的index.js文件處於緩存當中，因此不會重新加載模塊。當然我們也可以通過刪除require.cache來清空緩存內容，達到重新加載的目的，這裡不再演示。

三、總結

本文概述瞭使用Node.js模塊化時需要瞭解到的一些基本原理和常識，希望幫助大傢對Node.js模塊化有更清晰的認識。但更深入的細節並未在本文中闡述，例如wrapper函數內部的處理邏輯，CommonJS的同步加載的問題、與ES模塊的區別等等。這些未提到的內容大傢可以在本文以外做更多探索。

以上就是詳解NodeJS模塊化的詳細內容，更多關於NodeJS 模塊化的資料請關註WalkonNet其它相關文章！

詳解NodeJS模塊化

一、前言

二、正文

2.1、什麼是模塊

2.2、Resolving

2.3、require.resolve

2.4、模塊間的父子依賴關系

2.5、exports, module.exports

2.6、模塊循環依賴

2.7、.json和.node

2.8、Wrapping

2.9、Cache

三、總結

推薦閱讀：

發佈留言取消回覆

近期文章

一、前言

二、正文

2.1、什麼是模塊

2.2、Resolving

2.3、require.resolve

2.4、模塊間的父子依賴關系

2.5、exports, module.exports

2.6、模塊循環依賴

2.7、.json和.node

2.8、Wrapping

2.9、Cache

三、總結

推薦閱讀：

發佈留言 取消回覆

近期文章

標籤

發佈留言取消回覆