「Node.js系列」深入淺出Node模塊化開發(fā)——CommonJS規(guī)范
前言
本文將為大家透徹的介紹關(guān)于Node的模塊化——CommonJS的一切。
看完本文可以掌握,以下幾個方面:
什么是模塊化,以及沒有模塊化會帶來哪些問題,是如何解決的; JavaScript的設(shè)計缺陷; CommonJS規(guī)范; 它的規(guī)范特性; 如何配合Node完成模塊化開發(fā); exports如何導(dǎo)出的; module.exports是如何導(dǎo)出變量的,值類型和引用類型導(dǎo)出間的差異;從內(nèi)存角度深度分析 module.exports和exports又有怎樣的區(qū)別和聯(lián)系;require的細節(jié),以及模塊的加載執(zhí)行順序; CommonJS的加載過程; CommonJS規(guī)范的本質(zhì);
一.什么是模塊化?
在很多開發(fā)的情況下,我們都知道要使用模塊化開發(fā),那為什么要使用它呢?
而事實上,模塊化開發(fā)最終的目的是將程序劃分成一個個小的結(jié)構(gòu);
在這個結(jié)構(gòu)中編寫屬于 自己的邏輯代碼,有自己的作用域,不會影響到其他的結(jié)構(gòu);這個結(jié)構(gòu)可以將自己希望暴露的 變量、函數(shù)、對象等導(dǎo)出給其結(jié)構(gòu)使用;也可以通過某種方式,導(dǎo)入另外結(jié)構(gòu)中的 變量、函數(shù)、對象等;
上面說提到的結(jié)構(gòu),就是模塊;
按照這種結(jié)構(gòu)劃分開發(fā)程序的過程,就是模塊化開發(fā)的過程;
二.JavaScript設(shè)計缺陷
在網(wǎng)頁開發(fā)的早期,由于JavaScript僅僅作為一種腳本語言,只能做一些簡單的表單驗證或動畫實現(xiàn)等,它還是具有很多的缺陷問題的,比如:
var定義的變量作用域問題; JavaScript的面向?qū)ο蟛⒉荒芟癯R?guī)面向?qū)ο笳Z言一樣使用class; 在早期JavaScript并沒有模塊化的問題,所以也就沒有對應(yīng)的模塊化解決方案;
但隨著前端和JavaScript的快速發(fā)展,JavaScript代碼變得越來越復(fù)雜了;
ajax的出現(xiàn), 前后端開發(fā)分離,意味著后端返回數(shù)據(jù)后,我們需要通過JavaScript進行前端頁面的渲染;SPA的出現(xiàn),前端頁面變得更加復(fù)雜:包括 前端路由、狀態(tài)管理等等一系列復(fù)雜的需求需要通過JavaScript來實現(xiàn);包括Node的實現(xiàn),JavaScript編寫 復(fù)雜的后端程序,沒有模塊化是致命的硬傷;
所以,模塊化已經(jīng)是JavaScript一個非常迫切的需求:
但是JavaScript本身,直到
ES6(2015)才推出了自己的模塊化方案;在此之前,為了讓JavaScript支持模塊化,涌現(xiàn)出了很多不同的模塊化規(guī)范:
AMD、CMD、CommonJS等;
到此,我們明白了為什么要用模塊化開發(fā)?
那如果沒有模塊化會帶來什么問題呢?
三.沒有模塊化的問題
當我們在公司面對一個大型的前端項目時,通常是多人開發(fā)的,會把不同的業(yè)務(wù)邏輯分步在多個文件夾當中。
2.1 沒有模塊化給項目帶來的弊端
假設(shè)有兩個人,分別是小豪和小紅在開發(fā)一個項目 項目的目錄結(jié)構(gòu)是這樣的

小豪開發(fā)的bar.js文件
var name = "小豪";
console.log("bar.js----", name);
小豪開發(fā)的baz.js文件
console.log("baz.js----", name);
小紅開發(fā)的foo.js文件
var name = "小紅";
console.log("foo.js----", name);
引用路徑如下:
<body>
<script src="./bar.js"></script>
<script src="./foo.js"></script>
<script src="./baz.js"></script>
</body>
最后當我去執(zhí)行的時候,卻發(fā)現(xiàn)執(zhí)行結(jié)果:

當我們看到這個結(jié)果,有的小伙伴可能就會驚訝,baz.js文件不是小豪寫的么?為什么會輸出小紅的名字呢?
究其原因,我們才發(fā)現(xiàn),其實JavaScript是沒有模塊化的概念(至少到現(xiàn)在為止還沒有用到ES6規(guī)范),換句話說就是每個.js文件并不是一個獨立的模塊,沒有自己的作用域,所以在.js文件中定義的變量,都是可以被其他的地方共享的,所以小豪開發(fā)的baz.js里面的name,其實訪問的是小紅重新聲明的。
但是共享也有一點不好就是,項目的其他協(xié)作人員也可以隨意的改變它們,顯然這不是我們想要的。
2.2 IIFE解決早期的模塊化問題
所以,隨著前端的發(fā)展,模塊化變得必不可少,那么在早期是如何解決的呢?
在早期,因為函數(shù)是有自己的作用域,所以可以采用立即函數(shù)調(diào)用表達式(IIFE),也就是自執(zhí)行函數(shù),把要供外界使用的變量作為函數(shù)的返回結(jié)果。
小豪——bar.js
var moduleBar = (function () {
var name = "小豪";
var age = "18";
console.log("bar.js----", name, age);
return {
name,
age,
};
})();
小豪——baz.js
console.log("baz.js----", moduleBar.name);
console.log("baz.js----", moduleBar.age);
小紅——foo.js
(function () {
var name = "小紅";
var age = 20;
console.log("foo.js----", name, age);
})();
來看一下,解決之后的輸出結(jié)果,原調(diào)用順序不變;

但是,這又帶來了新的問題:
我必須記得每一個 模塊中返回對象的命名,才能在其他模塊使用過程中正確的使用;代碼寫起來 雜亂無章,每個文件中的代碼都需要包裹在一個匿名函數(shù)中來編寫;在 沒有合適的規(guī)范情況下,每個人、每個公司都可能會任意命名、甚至出現(xiàn)模塊名稱相同的情況;
所以現(xiàn)在急需一個統(tǒng)一的規(guī)范,來解決這些缺陷問題,就此CommonJS規(guī)范問世了。
三.Node模塊化開發(fā)——CommonJS規(guī)范
3.1 CommonJS規(guī)范特性
CommonJS是一個規(guī)范,最初提出來是在瀏覽器以外的地方使用,并且當時被命名為ServerJS,后來為了體現(xiàn)它的廣泛性,修改為CommonJS規(guī)范。
Node是CommonJS在服務(wù)器端一個具有代表性的實現(xiàn);
Browserify是CommonJS在瀏覽器中的一種實現(xiàn);
webpack打包工具具備對CommonJS的支持和轉(zhuǎn)換;
正是因為Node中對CommonJS進行了支持和實現(xiàn),所以它具備以下幾個特點;
在Node中 每一個js文件都是一個單獨的模塊;該模塊中,包含 CommonJS規(guī)范的核心變量: exports、module.exports、require;使用核心變量,進行 模塊化開發(fā);
無疑,模塊化的核心是導(dǎo)出和導(dǎo)入,Node中對其進行了實現(xiàn):
exports和module.exports可以負責 對模塊中的內(nèi)容進行導(dǎo)出;require函數(shù)可以幫助我們 導(dǎo)入其他模塊(自定義模塊、系統(tǒng)模塊、第三方庫模塊)中的內(nèi)容;
3.2 CommonJS配合Node模塊化開發(fā)
假設(shè)現(xiàn)在有兩個文件:
bar.js
const name = "時光屋小豪";
const age = 18;
function sayHello(name) {
console.log("hello" + name);
}
main.js
console.log(name);
console.log(age);
執(zhí)行node main.js之后,會看到

這是因為在當前main.js模塊內(nèi),沒有發(fā)現(xiàn)name這個變量;
這點與我們前面看到的明顯不同,因為Node中每個js文件都是一個單獨的模塊。
那么如果要在別的文件內(nèi)訪問bar.js變量
bar.js需要導(dǎo)出自己想要暴露的變量、函數(shù)、對象等等;main.js從bar.js引入想用的變量、函數(shù)、對象等等;

3.3 exports導(dǎo)出
exports是一個對象,我們可以在這個對象中添加很多個屬性,添加的屬性會導(dǎo)出。
bar.js文件導(dǎo)出:
const name = "時光屋小豪";
const age = 18;
function sayHello(name) {
console.log("hello" + name);
}
exports.name = name;
exports.age = age;
exports.sayHello = sayHello;
main.js文件導(dǎo)入:
const bar = require('./bar');
console.log(bar.name); // 時光屋小豪
console.log(bar.age); // 18
其中要注意的點:
main.js中的 bar變量等于exports對象;
bar = exports
所以我們通過
bar.xxx來使用導(dǎo)出文件內(nèi)的變量,比如name,age;require其實是一個函數(shù),返回值是一個對象,值為“導(dǎo)出文件”的exports對象;
3.4 從內(nèi)存角度分析bar和exports是同一個對象
在Node中,有一個特殊的全局對象,其實exports就是其中之一。
如果在文件內(nèi),不再使用exports.xxx的形式導(dǎo)出某個變量的話,其實exports就是一個空對象。

模塊之間的引用關(guān)系

當我們在 main.js中require導(dǎo)入的時候,它會去自動查找特殊的全局對象exports,并且把require函數(shù)的執(zhí)行結(jié)果賦值給bar;bar和exports指向同一個引用(引用地址相同);如果發(fā)現(xiàn) exports上有變量,則會放到bar對象上,正因為這樣我們才能從bar上讀取想用的變量;
為了進一步論證,bar和exports是同一個對象:
我們加入定時器看看

所以綜上所述,Node中實現(xiàn)CommonJS規(guī)范的本質(zhì)就是對象的引用賦值(淺拷貝本質(zhì))。
把exports對象的引用賦值bar對象上。
CommonJS規(guī)范的本質(zhì)就是對象的引用賦值
3.5 module.exports又是什么?
但是Node中我們經(jīng)常使用module.exports導(dǎo)出東西,也會遇到這樣的面試題:
module.exports和exports有什么關(guān)系或者區(qū)別呢?
3.6 require細節(jié)
require本質(zhì)就是一個函數(shù),可以幫助我們引入一個文件(模塊)中導(dǎo)入的對象。
require的查找規(guī)則https://nodejs.org/dist/latest-v14.x/docs/api/modules.html#modules_all_together
3.7 require模塊的加載順序
結(jié)論一: 模塊在被第一次引入時,模塊中的js代碼會被運行一次
// aaa.js
const name = 'coderwhy';
console.log("Hello aaa");
setTimeout(() => {
console.log("setTimeout");
}, 1000);
// main.js
const aaa = require('./aaa');
aaa.js中的代碼在引入時會被運行一次
結(jié)論二:模塊被多次引入時,會緩存,最終只加載(運行)一次
// main.js
const aaa = require('./aaa');
const bbb = require('./bbb');
/// aaa.js
const ccc = require("./ccc");
// bbb.js
const ccc = require("./ccc");
// ccc.js
console.log('ccc被加載');
ccc中的代碼只會運行一次。
為什么只會加載運行一次呢?
每個模塊對象module都有一個屬性:loaded; 為false表示還沒有加載; 為true表示已經(jīng)加載;
結(jié)論三:如果有循環(huán)引入,那么加載順序是什么?
如果出現(xiàn)下面模塊的引用關(guān)系,那么加載順序是什么呢?
這個其實是一種數(shù)據(jù)結(jié)構(gòu):圖結(jié)構(gòu); 圖結(jié)構(gòu)在遍歷的過程中,有深度優(yōu)先搜索(DFS, depth first search)和廣度優(yōu)先搜索(BFS, breadth first search); Node采用的是深度優(yōu)先算法:main -> aaa -> ccc -> ddd -> eee ->bbb;

四.module.exports
4.1 真正導(dǎo)出的是module.exports
以下是通過維基百科對CommonJS規(guī)范的解析:
CommonJS中是沒有module.exports的概念的;
但是為了實現(xiàn)模塊的導(dǎo)出,Node中使用的是
Module的類,每一個模塊都是Module的一個實例module;所以在Node中真正用于導(dǎo)出的其實根本不是
exports,而是module.exports;exports只是module上的一個對象
但是,為什么exports也可以導(dǎo)出呢?
這是因為
module對象的exports屬性是exports對象的一個引用;等價于
module.exports = exports = main中的bar(CommonJS內(nèi)部封裝);
4.2 module.exports和exports有什么關(guān)系或者區(qū)別呢?
聯(lián)系:module.exports = exports
進一步論證module.exports = exports
// bar.js
const name = "時光屋小豪";
exports.name = name;
setTimeout(() => {
module.exports.name = "哈哈哈";
console.log("bar.js中1s之后", exports.name);
}, 1000);
// main.js
const bar = require("./bar");
console.log("main.js", bar.name);
setTimeout((_) => {
console.log("main.js中1s之后", bar.name);
}, 2000);

在上面代碼中,只要在bar.js中修改exports對象里的屬性,導(dǎo)出的結(jié)果都會變,因為即使真正導(dǎo)出的是 module.exports,而module.exports和exports是都是相同的引用地址,改變了其中一個的屬性,另一個也會跟著改變。
注意:真正導(dǎo)出的模塊內(nèi)容的核心其實是module.exports,只是為了實現(xiàn)CommonJS的規(guī)范,剛好module.exports對exports對象使用的是同一個引用而已

區(qū)別:有以下兩點
那么如果,代碼這樣修改了:

module.exports也就和exports沒有任何關(guān)系了;無論 exports怎么改,都不會影響最終的導(dǎo)出結(jié)果;因為
module.exports = { xxx }這樣的形式,會在堆內(nèi)存中新開辟出一塊內(nèi)存空間,會生成一個新的對象,用它取代之前的exports對象的導(dǎo)出那么也就意味著 require導(dǎo)入的對象是新的對象;

講完它們兩個的區(qū)別,來看下面這兩個例子,看看自己是否真正掌握了module.exports的用法
4.3 關(guān)于module.exports的練習(xí)題
練習(xí)1:導(dǎo)出的變量為值類型
// bar.js
let name = "時光屋小豪";
setTimeout(() => {
name = "123123";
}, 1000);
module.exports = {
name: name,
age: "20",
sayHello: function (name) {
console.log("你好" + name);
},
};
// main.js
const bar = require("./bar");
console.log("main.js", bar.name); // main.js 時光屋小豪
setTimeout(() => {
console.log("main.js中2s后", bar.name); // main.js中2s后 時光屋小豪
}, 2000);
練習(xí)2:導(dǎo)出的變量為引用類型
// bar.js
let info = {
name: "時光屋小豪",
};
setTimeout(() => {
info.name = "123123";
}, 1000);
module.exports = {
info: info,
age: "20",
sayHello: function (name) {
console.log("你好" + name);
},
};
// main.js
const bar = require("./bar");
console.log("main.js", bar.info.name); // main.js 時光屋小豪
setTimeout(() => {
console.log("main.js中2s后", bar.info.name); // main.js中2s后 123123
}, 2000);
從main.js輸出結(jié)果來看,定時器修改的name變量的結(jié)果,并沒有影響main.js中導(dǎo)入的結(jié)果。
因為name為值類型,基本類型,一旦定義之后,就把其屬性值,放到了 module.exports的內(nèi)存里(練1)因為info為引用類型,所以 module.exports里存放的是info的引用地址,所以由定時器更改的變量,會影響main.js導(dǎo)入的結(jié)果(練2)

五.CommonJS的加載過程
CommonJS模塊加載js文件的過程是運行時加載的,并且是同步的:
運行時加載意味著是js引擎在執(zhí)行js代碼的過程中加載模塊; 同步的就意味著一個文件沒有加載結(jié)束之前,后面的代碼都不會執(zhí)行;
const flag = true;
if (flag) {
const foo = require('./foo');
console.log("等require函數(shù)執(zhí)行完畢后,再輸出這句代碼");
}
CommonJS通過module.exports導(dǎo)出的是一個對象:
導(dǎo)出的是一個對象意味著可以將這個對象的引用在其他模塊中賦值給其他變量; 但是最終他們指向的都是同一個對象,那么一個變量修改了對象的屬性,所有的地方都會被修改;
六.CommonJS規(guī)范的本質(zhì)
CommonJS規(guī)范的本質(zhì)就是對象的引用賦值
后續(xù)文章
《JavaScript模塊化——ES Module》
在下一篇文章中,
會重點講解ES Module規(guī)范的一切; 及CommonJS和ES Module是如何交互的; 類比CommonJS和ES Module優(yōu)缺點,如何完美的回答這道面試題;
感謝大家??
如果你覺得這篇內(nèi)容對你挺有啟發(fā),我想邀請你幫我三個小忙:
點個「在看」,讓更多的人也能看到這篇內(nèi)容(喜歡不點在看,都是耍流氓 -_-) 歡迎聯(lián)系我噢,微信「TH0000666」。 關(guān)注公眾號「前端Sharing」,持續(xù)為你推送精選好文。
