模塊包和commonjs,模塊包和庫

本文目錄一覽：

• 1、ECMAScript 6 的模塊相比 CommonJS 的 有什麼優點
• 2、ES6 模塊與 CommonJS 模塊的差異
• 3、react+webpack 模塊化應該採用CommonJS規範還是ES6規範，為什麼
• 4、CMD 規範是不是就是 commonJS 規範
• 5、如何讓模塊支持AMD/CMD和commonjs標準
• 6、webpack打包原理

ECMAScript 6 的模塊相比 CommonJS 的 有什麼優點

ECMAScript 6 很多新功能都是毀譽參半，其中添加的一個新功能「模塊 Module」也一樣，有人認為 Module 可以幫助我們更好地寫代碼，也有人認為這增加了 Javascript 的複雜度，大多數人其實並不需要它。

到底是好是壞，這裡不去辯別。但目前 Module 的語法已經定下來了，我們可以來探索下它。

ES6 模塊與 CommonJS 模塊的差異

討論 Node.js 載入 ES6 模塊之前，必須了解 ES6 模塊與 CommonJS 模塊完全不同。

它們有三個重大差異。

第二個差異是因為 CommonJS 載入的是一個對象（即module.exports屬性），該對象只有在腳本運行完才會生成。而 ES6 模塊不是對象，它的對外介面只是一種靜態定義，在代碼靜態解析階段就會生成。

下面重點解釋第一個差異。

CommonJS 模塊輸出的是值的拷貝，也就是說，一旦輸出一個值，模塊內部的變化就影響不到這個值。請看下面這個模塊文件lib.js的例子。

上面代碼輸出內部變數counter和改寫這個變數的內部方法incCounter。然後，在main.js裡面載入這個模塊。

上面代碼說明，lib.js模塊載入以後，它的內部變化就影響不到輸出的mod.counter了。這是因為mod.counter是一個原始類型的值，會被緩存。除非寫成一個函數，才能得到內部變動後的值。

上面代碼中，輸出的counter屬性實際上是一個取值器函數。現在再執行main.js，就可以正確讀取內部變數counter的變動了。

上面代碼說明，ES6 模塊輸入的變數counter是活的，完全反應其所在模塊lib.js內部的變化。

再舉一個出現在export一節中的例子。

上面代碼中，m1.js的變數foo，在剛載入時等於bar，過了 500 毫秒，又變為等於baz。

讓我們看看，m2.js能否正確讀取這個變化。

上面代碼表明，ES6 模塊不會緩存運行結果，而是動態地去被載入的模塊取值，並且變數總是綁定其所在的模塊。

由於 ES6 輸入的模塊變數，只是一個「符號連接」，所以這個變數是只讀的，對它進行重新賦值會報錯。

上面代碼中，main.js從lib.js輸入變數obj，可以對obj添加屬性，但是重新賦值就會報錯。因為變數obj指向的地址是只讀的，不能重新賦值，這就好比main.js創造了一個名為obj的const變數。

最後，export通過介面，輸出的是同一個值。不同的腳本載入這個介面，得到的都是同樣的實例。

上面的腳本mod.js，輸出的是一個C的實例。不同的腳本載入這個模塊，得到的都是同一個實例。

現在執行main.js，輸出的是1。

這就證明了x.js和y.js載入的都是C的同一個實例。

react+webpack 模塊化應該採用CommonJS規範還是ES6規範，為什麼

研究react的時候也考慮過這個問題，首先可以先了解下這兩種模塊的機制。參考這裡

要考慮的點：

目前Commonjs是nodejs(瀏覽器環境需要模塊載入器)原生支持的，而es6需要藉助babeljs來實現。意味著如果要實現自動編譯上線(我司沒有在線上安裝node_modules做法)可能需要將babel之類的node_modules提交代碼倉庫，大概45M。

還有要考慮下你選擇的react的組件庫是基於es6還是Commonjs。如果你業務使用Commonjs規範，組件使用es6，這個就沒法統一了。

考慮下團隊對es6的熟悉程度，關係到代碼質量和維護成本。

暫時就想到這些。

CMD 規範是不是就是 commonJS 規範

CMD是國內玉伯大神在開發SeaJS的時候提出來的，屬於CommonJS的一種規範，此外還有AMD，其對於的框架是RequireJS

1、二者都是非同步模塊定義（Asynchronuous Module Definition）的一個實現；

2、CMD和AMD都是CommonJS的一種規範的實現定義，RequireJS和SeaJS是對應的實踐；

3、CMD和AMD的區別:CMD相當於按需載入，定義一個模塊的時候不需要立即制定依賴模塊，在需要的時候require就可以了，比較方便；而AMD則相反，定義模塊的時候需要制定依賴模塊，並以形參的方式引入factory中。

區別看下邊例子：

//AMD方式定義模塊

define([‘dep1′,’dep2’],function(dep1,dep2){

//內部只能使用制定的模塊

return function(){};

});

//CMD

define(function(require,exports,module){

//此處如果需要某XX模塊，可以引入

var xx=require(‘XX’);

});

4、JavaScript語言是弱結構性的，通過CommonJS定義一些規範，CMD和AMD得定義模塊的方式對代碼進行管理，使得更易維護；此外，NodeJS的誕生，對模塊的規範定義，和包（npm）的概念的引入，讓JS管理不再困難，一個字，爽爆了！

如何讓模塊支持AMD/CMD和commonjs標準

CommonJS是伺服器端模塊的規範，Node.js採用了這個規範。 根據CommonJS規範，一個單獨的文件就是一個模塊。載入模塊使用require方法，該方法讀取一個文件並執行，最後返迴文件內部的exports對象。下面就是一個簡單的模塊文件example.js。

webpack打包原理

webpack打包原理是根據文件間的依賴關係對其進行靜態分析，然後將這些模塊按指定規則生成靜態資源，當 webpack 處理程序時，它會遞歸地構建一個依賴關係圖(dependency graph)，其中包含應用程序需要的每個模塊，然後將所有這些模塊打包成一個或多個 bundle。

webpack有兩種組織模塊的依賴方式，同步、非同步。非同步依賴將作為分割點，形成一個新的塊；在優化了依賴樹之後，每一個非同步區塊都將作為一個文件被打包。

webpack有一個智能解析器，幾乎可以處理任何第三方庫。無論它們的模塊形式是CommonJS、AMD還是普通的JS文件；甚至在載入依賴的時候，允許使用動態表require(“、/templates/”+name+”、jade”)。

擴展資料

在使用webpack構建的典型應用程序或站點中，有三種主要的代碼類型：

1、團隊編寫的源碼。

2、源碼會依賴的任何第三方的library或”vendor”代碼。

3、webpack的runtime和manifest，管理所有模塊的交互。

runtime 包含：在模塊交互時，連接模塊所需的載入和解析邏輯；包括瀏覽器中的已載入模塊的連接，以及懶載入模塊的執行邏輯。