webpack模塊解析

前面的話

　　在web存在多種支持JavaScript模塊化的工具(如requirejs和r.js)，這些工具各有優點和限制。webpack基於從這些系統得到的經驗教訓，並將模塊的概念應用於項目中的任何文件。本文將詳細介紹webpack的模塊解析

 

模塊

　　在模塊化編程中，開發者將程序分解成離散功能塊(discrete chunks of functionality)，並稱之爲模塊

　　每一個模塊具備比完整程序更小的接觸面，使得校驗、調試、測試垂手可得。 精心編寫的模塊提供了可靠的抽象和封裝界限，使得應用程序中每一個模塊都具備條理清楚的設計和明確的目的

　　Node.js從最一開始就支持模塊化編程。對比Node.js模塊，webpack模塊可以以各類方式表達它們的依賴關係

ES2015 import 語句
CommonJS require() 語句
AMD define 和 require 語句
css/sass/less 文件中的 @import 語句。
樣式(url(...))或 HTML 文件(<img src=...>)中的圖片連接(image url)

　　[注意]webpack 1須要特定的loader來轉換ES 2015 import，然而經過webpack 2能夠開箱即用

【支持類型】

　　webpack經過loader能夠支持各類語言和預處理器編寫模塊。loader描述了webpack如何處理非JavaScript(non-JavaScript) 模塊，而且在bundle中引入這些依賴。 webpack 社區已經爲各類流行語言和語言處理器構建了loader，包括：

CoffeeScript
TypeScript
ESNext (Babel)
Sass
Less
Stylus

　　總的來講，webpack提供了可定製的、強大和豐富的API，容許任何技術棧使用webpack，保持了在開發、測試和生成流程中無侵入性(non-opinionated)

 

模塊解析

　　resolver是一個庫(library)，用於幫助找到模塊的絕對路徑。一個模塊能夠做爲另外一個模塊的依賴模塊，而後被後者引用，以下：

import foo from 'path/to/module'
// 或者
require('path/to/module')

　　所依賴的模塊能夠是來自應用程序代碼或第三方的庫(library)。resolver幫助webpack找到bundle中須要引入的模塊代碼，這些代碼在包含在每一個require/import語句中。當打包模塊時，webpack使用enhanced-resolve來解析文件路徑

【解析規則】

　　使用enhanced-resolve，webpack可以解析三種文件路徑：

　　一、絕對路徑

import "/home/me/file";
import "C:\\Users\\me\\file";

　　因爲已經取得文件的絕對路徑，所以不須要進一步再作解析

　　二、相對路徑

import "../src/file1";
import "./file2";

　　在這種狀況下，使用import或require的資源文件(resource file)所在的目錄被認爲是上下文目錄(context directory)。在import/require中給定的相對路徑，會添加此上下文路徑(context path)，以產生模塊的絕對路徑(absolute path)

　　三、模塊路徑

import "module";
import "module/lib/file";

　　模塊將在resolve.modules中指定的全部目錄內搜索。 能夠替換初始模塊路徑，此替換路徑經過使用resolve.alias配置選項來建立一個別名

　　一旦根據上述規則解析路徑後，解析器(resolver)將檢查路徑是否指向文件或目錄

　　若是路徑指向一個文件：

　　　　a、若是路徑具備文件擴展名，則被直接將文件打包

　　　　b、不然，將使用 [resolve.extensions] 選項做爲文件擴展名來解析，此選項告訴解析器在解析中可以接受哪些擴展名（例如 .js, .jsx）

　　若是路徑指向一個文件夾，則採起如下步驟找到具備正確擴展名的正確文件：

　　　　a、若是文件夾中包含 package.json 文件，則按照順序查找 resolve.mainFields 配置選項中指定的字段。而且 package.json 中的第一個這樣的字段肯定文件路徑

　　　　b、若是package.json文件不存在或者package.json文件中的main字段沒有返回一個有效路徑，則按照順序查找 esolve.mainFiles配置選項中指定的文件名，看是否能在import/require目錄下匹配到一個存在的文件名

　　　　c、文件擴展名經過 resolve.extensions 選項採用相似的方法進行解析

　　webpack 根據構建目標(build target)爲這些選項提供了合理的默認配置

【解析與緩存】

　　Loader解析遵循與文件解析器指定的規則相同的規則。resolveLoader 配置選項能夠用來爲 Loader 提供獨立的解析規則。

　　每一個文件系統訪問都被緩存，以便更快觸發對同一文件的多個並行或穿行請求。在觀察模式下，只有修改過的文件會從緩存中摘出。若是關閉觀察模式，在每次編譯前清理緩存

 

依賴圖表

　　任什麼時候候，一個文件依賴於另外一個文件，webpack就把此視爲文件之間有依賴關係。這使得 webpack 能夠接收非代碼資源(non-code asset)（例如圖像或 web 字體），而且能夠把它們做爲依賴提供給應用程序

　　webpack從命令行或配置文件中定義的一個模塊列表開始，處理應用程序。 從這些入口起點開始，webpack 遞歸地構建一個依賴圖表，這個依賴圖表包含着應用程序所需的每一個模塊，而後將全部這些模塊打包爲少許的bundle(一般只有一個 )可由瀏覽器加載

 

構建目標

　　由於服務器和瀏覽器代碼均可以用JavaScript編寫，因此webpack提供了多種構建目標(target)，能夠在webpack配置中設置

【用法】

　　要設置target屬性，只須要在webpack配置中設置target的值

//webpack.config.js
module.exports = {
  target: 'node'
};

　　在上面例子中，使用node webpack會編譯爲用於「類Node.js」環境（使用Node.js的require，而不是使用任意內置模塊（如fs或path）來加載chunk）。

　　每一個target都有各類部署(deployment)/環境(environment)特定的附加項，以支持知足其需求

【多個Target】

　　儘管webpack不支持向target傳入多個字符串，能夠經過打包兩份分離的配置來建立同構的庫

//webpack.config.js
var path = require('path');
var serverConfig = {
  target: 'node',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'lib.node.js'
  }
  //…
};
var clientConfig = {
  target: 'web', // <=== 默認是 'web'，可省略
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'lib.js'
  }
  //…
};
module.exports = [ serverConfig, clientConfig ];

　　上面的例子將在的dist文件夾下建立lib.js和lib.node.js文件

 

模塊熱替換

　　模塊熱替換HMR(Hot Module Replacement)功能會在應用程序運行過程當中替換、添加或刪除模塊，而無需從新加載頁面。這使得能夠在獨立模塊變動後，無需刷新整個頁面，就能夠更新這些模塊，極大地加速了開發時間

【站在App的角度】

　　一、app代碼要求HMR runtime 檢查更新

　　二、HMR runtime （異步）下載更新，而後通知 app 代碼更新可用

　　三、app 代碼要求 HMR runtime 應用更新

　　四、HMR runtime （異步）應用更新

　　能夠設置 HMR，使此進程自動觸發更新，或者能夠選擇要求在用戶交互後進行更新

【站在編譯器(webpack)的角度】

　　除了普通資源，編譯器(compiler)須要發出 "update"，以容許更新以前的版本到新的版本。"update" 由兩部分組成：一、待更新manifest (JSON)；二、一個或多個待更新chunk (JavaScript)；

　　manifest 包括新的編譯 hash 和全部的待更新 chunk 目錄。

　　每一個待更新 chunk 包括用於與全部被更新模塊相對應 chunk 的代碼（或一個 flag 用於代表模塊要被移除）。

　　編譯器確保模塊 ID 和 chunk ID 在這些構建之間保持一致。一般將這些 ID 存儲在內存中（例如，當使用 webpack-dev-server 時），可是也可能將它們存儲在一個 JSON 文件中

【站在模塊的角度】

　　HMR 是可選功能，只會影響包含 HMR 代碼的模塊。舉個例子，經過 style-loader 爲 style 樣式追加補丁。 爲了運行追加補丁，style-loader 實現了 HMR 接口；當它經過 HMR 接收到更新，它會使用新的樣式替換舊的樣式。

　　相似的，當在一個模塊中實現了 HMR 接口，能夠描述出當模塊被更新後發生了什麼。然而在多數狀況下，不須要強制在每一個模塊中寫入 HMR 代碼。若是一個模塊沒有 HMR 處理函數，更新就會冒泡。這意味着一個簡單的處理函數可以對整個模塊樹(complete module tree)進行處理。若是在這個模塊樹中，一個單獨的模塊被更新，那麼整個模塊樹都會被從新加載（只會從新加載，不會遷移）。

【站在HMR Runtime的角度】

　　對於模塊系統的 runtime，附加的代碼被髮送到 parents 和 children 跟蹤模塊。

　　在管理方面，runtime 支持兩個方法 check 和 apply。

　　一、check 發送 HTTP 請求來更新 manifest。若是請求失敗，說明沒有可用更新。若是請求成功，待更新 chunk 會和當前加載過的 chunk 進行比較。對每一個加載過的 chunk，會下載相對應的待更新 chunk。當全部待更新 chunk 完成下載，就會準備切換到 ready 狀態。

　　二、apply 方法將全部被更新模塊標記爲無效。對於每一個無效模塊，都須要在模塊中有一個更新處理函數，或者在它的父級模塊們中有更新處理函數。不然，無效標記冒泡，並將父級也標記爲無效。每一個冒泡繼續直到到達應用程序入口起點，或者到達帶有更新處理函數的模塊（以最早到達爲準）。若是它從入口起點開始冒泡，則此過程失敗。

　　以後，全部無效模塊都被（經過 dispose 處理函數）處理和解除加載。而後更新當前 hash，而且調用全部 "accept" 處理函數。runtime 切換回閒置狀態，一切照常繼續

　　能夠在開發過程當中將 HMR 做爲 LiveReload 的替代。webpack-dev-server 支持熱模式，在試圖從新加載整個頁面以前，熱模式會嘗試使用 HMR 來更新

　　一些 loader 已經生成可熱更新的模塊。例如，style-loader 可以置換出頁面的樣式表。對於這樣的模塊，不須要作任何特殊處理