摘要：之輸出的最后就是為了得到打包結果。在這里可以看到很多相似，但是有不同含義的名次，如和，和，那他們有什么區別呢而這里的又是什么意思呢將多個模塊打包之后的代碼集合稱為。在這樣打包的話，會報錯。所以就想搞明白這兩個的區別到底是什么。

webpack的最后就是為了得到打包結果。

那這是一個怎么樣的過程，不同的配置，會有什么樣的結果呢？

本文的原文在我的博客中:github.com/RachelRen/b…,歡迎star。

首先從最簡單的配置開始output。告訴webpack在哪里打包應用程序。

	output: {
	    path: path.resolve(__dirname, "build"),
	    filename: "js/[name].js",
	    publicPath: "/",
	    chunkFilename:"js/[name].chunk.js",
		//chunkFilename:"js/[name].[chunkhash:8].chunk.js",
	},

在這里可以看到很多相似，但是有不同含義的名次，如filename和chunkFilename，hash和chunkhash，那他們有什么區別呢？

而這里的chunk又是什么意思呢？

webpack 將多個模塊打包之后的代碼集合稱為 chunk。 這兩個的區別：chunkFilename 是無入口的chunk在輸出時的文件名稱。chunkFilename只用于在指定在運行過程中生成的chunk在輸出時的文件名稱。

但在webpack4以上的時候，發現在entry中配置的入口文件，打包的結果是index.chunckfile.js,屬于chunkFilename，因為設置了

optimization: {
    splitChunks: {
      	chunks: "all",
     	name: "common",
    },
    runtimeChunk: { 
     	name: "runtime",
    }
},

當去掉runtimeChunk這個配置時，那么入口文件，又會變成filename。主要原因是

通過設置 optimization.splitChunks.chunks: "all" 來啟動默認的代碼分割配置項。通過滿足下面的條件，webpack會自動打包chunks

當前模塊是公共模塊（多處引用）或者模塊來自 node_modules

當前模塊大小大于 30kb

如果此模塊是按需加載，并行請求的最大數量小于等于 5

如果此模塊在初始頁面加載，并行請求的最大數量小于等于 3

optimization.runtimeChunk

通過設置 optimization.runtimeChunk: true 來為每一個入口默認添加一個只包含 runtime 的 chunk(webpack會添加一個只包含運行時(runtime)額外代碼塊到每一個入口)。

output: {
	filename: "js/[name].[chunkhash:8].js",
	path: path.join(__dirname, "./build"),
    publicPath: "/",
    chunkFilename:"js/[name].[chunkhash:8].chunk.js",
},

在webpack 4這樣打包的話，會報錯。

ERROR in chunk runtime [entry]
js/[name].[chunkhash:8].js
Cannot use [chunkhash] or [contenthash] for chunk in "js/[name].[chunkhash:8].js" (use [hash] instead)

所以就想搞明白這兩個的區別到底是什么。

[chunkhash] is replaced by the hash of the chunk.

chunkhash代表的是chunk的hash值。chunk在webpack中的就是模塊的意思，那么chunkhash就是根據模塊內容計算得出的hash值。

[hash] is replaced by the hash of the compilation.

hash 是compilation的hash值。

compilation對象代表某個版本的資源對應的編譯進程。在使用webpack的development中間件時，每次檢測到項目文件有變動時會創建一個compilation，所以能夠針對改動生成全新的編譯文件。compilation對象包含當前模塊資源，編譯文件，有改動的文件盒監聽依賴的所有信息。

compiler和compilation的區別是。 compiler是配置完備的webpack環境。compiler只在webpack啟動時構建一次，由webpack組合所有的配置構建生成。compiler是不變的webpack環境，是針對webpack的。而compilation是針對隨時可變的項目文件，只要有文件改動，compilation就會被重新創建。

compilation在項目中任何一個文件改動后就會被重新創建，然后webpack計算新的compilation的hash值，這個hash值便是hash。

hash是compilation對象(所用compilation對象？)計算所得，而不是具體的項目文件計算所得。所以以上配置的編譯輸出文件，所有的文件名都會使用相同的hash指紋。

chunkhash是根據具體模塊文件的內容計算所得的hash值，所以某個文件的改動只會影響它本身的hash指紋，不會影響其他文件

接上文所述，webpack的hash字段是根據每次編譯compilation的內容計算所得，也可以理解為項目總體文件的hash值，而不是針對每個具體文件的。

所以如果用optimization.splitChunks.runtimeChunk生成的文件，就是以hash作為文件后綴的runtime.[hash].js,而且每次文件修改，都會生成一個新的文件。

hash是跟整個項目的構建相關，只要項目里有文件更改，整個項目構建的hash值都會更改，并且全部文件都共用相同的hash值

總之一句話： hash是整體的文件計算所得，chunkhash是具體模塊文件所得。

現在很多系統都是SPA，當發展越來越龐大的時候，js的拆分就越來越重要的。那么怎么拆分js就很重要了。

分離主要有三種方式：

入口起點：使用 entry 配置手動地分離代碼。

防止重復：使用 SplitChunksPlugin 去重和分離 chunk。

動態導入：通過模塊中的內聯函數調用來分離代碼。

這種方式是最簡單，最直觀的方式。但是有一些他的缺點：

如果入口 chunk 之間包含一些重復的模塊，那些重復模塊都會被引入到各個 bundle 中。

這種方法不夠靈活，并且不能動態地將核心應用程序邏輯中的代碼拆分出來。

SplitChunksPlugin 插件可以將公共的依賴模塊提取到已有的 entry chunk 中，或者提取到一個新生成的 chunk。在webpack 4.0 之前是用CommonsChunkPlugin來做代碼分離的

plugins: [
  new webpack.optimize.CommonsChunkPlugin({
    names: ["vendor", "manifest"]
  })
]

在webpack 4.0之后，就通過optimization.splitChunks來分離代碼了。

optimization: {
    splitChunks: {
       chunks: "all"
    }
}

如果系統很龐大，將代碼一次性載入，就顯得太過于強大，最好能做到根據我們的需求來選擇性地加載我們需要的代碼。

webpack 提供了2種方式來拆分代碼。

符合 ECMAScript 提案 的 import() 語法 來實現動態導入。（import() 調用會在內部用到 promises。）

則是 webpack 的遺留功能，使用 webpack 特定的 require.ensure

在配置過程中，也會遇到這兩個概念。

publicPath： 用來為項目中的所有資源指定一個基礎路徑。使用的是相對路徑。

filename:"[name]_[chunkhash:8].js"
publicPath: "https://cdn.example.com/assets/"

那么發布上線的時候，路徑就是:

靜態資源最終訪問路徑 = output.publicPath + 資源loader或插件等配置路徑

path: 配置輸出文件存放在本地的目錄，必須是 string 類型的絕對路徑,通常通過 Node.js 的 path 模塊去獲取絕對路徑：

path: path.resolve(__dirname, "dist_[hash]")

Webpack中hash與chunkhash的區別，以及js與css的hash指紋解耦方案

腦闊疼的webpack按需加載

代碼分離