希望做瀏覽器長緩存？關于Webpack生成的Hash，你應該知道這些

stefan 發布于2019-08-06 13:27 / 1407人閱讀

摘要：之后的配置都是用作為生成因為要處理不同模塊的依賴關系，所以他內置了一個模板用來處理依賴關系后面稱為，這段因此也會被打包的我們最后里面。于是我們又打包恩，熟悉的味道。

童鞋，你看到這篇文章的時候很可能你只是在找一篇webpack的配置文章教學，但是聽老哥說一句，別去搜什么startkit或者best practice文章，特別是中文的，如果你找到了，也記得看一下文章啥時候寫的，超過半年的文章就別看了，百分之92.6里面的內容已經過期了。你想學webpack相關的姿勢，最好的辦法就是：看文檔

言歸正傳，這篇文章并不教你怎么配置webpack，內容全部都是關于webpack生成文件的hash的。在打包出來的文件名上加上文件內容的hash是目前最常見的有效使用瀏覽器長緩存的方法，js文件如果有內容更新，hash就會更新，瀏覽器請求路徑變化所以更新緩存，如果js內容不變，hash不變，直接用緩存，PERFECT！所以所有的問題就留給如何更好得控制文件的hash了。

基本

首先我們弄一個最簡單的webpack配置：

const path = require("path")

module.exports = {
  entry: {
    app: path.join(__dirname, "src/foo.js")
  },
  output: {
    filename: "[name].[chunkhash].js",
    path: path.join(__dirname, "dist")
  }
}

而我們foo.js如下：

import React from "react"
console.log(React.toString())

注意這里的output.filename你也可以用[hash]而不是[chunkhash]，但是這兩種生成的hash碼是不一樣的
使用hash如下：

app.03700a98484e0f02c914.js  70.4 kB       0  [emitted]  app
   [6] ./src/foo.js 55 bytes {0} [built]
    + 11 hidden modules

使用chunkhash如下：

app.f2f78b37e74027320ebf.js  70.4 kB       0  [emitted]  app
   [6] ./src/foo.js 55 bytes {0} [built]
    + 11 hidden modules

對于單個entry來說用哪個都沒有問題，做例子期間使用的是webpack@3.8.1版本，這個版本webpack對于源碼沒有改動的情況，已經修復了hash串會變的問題。但是在之前的版本有可能會出現對于同一份沒有修改的代碼進行修改，hash不一致的問題，所以不管你使用的版本會不會有問題，都建議使用接下去的配置。之后的配置都是用chunkhash作為hash生成

hash vs chunkhash

因為webpack要處理不同模塊的依賴關系，所以他內置了一個js模板用來處理依賴關系（后面稱為runtime），這段js因此也會被打包的我們最后bundle里面。在實際項目中我們常常需要將這部分代碼分離出來，比如我們要把類庫分開打包的情況，如果不多帶帶給runtime多帶帶生成一個js，那么他會和類庫一起打包，而這部分代碼會隨著業務代碼改變而改變，導致類庫的hash也每次都改變，那么我們分離出類庫就沒有意義了。所以這里我們需要給runtime多帶帶提供一個js。

修改配置如下：

module.exports = {
  entry: {
    app: path.join(__dirname, "src/foo.js")
  },
  output: {
    filename: "[name].[chunkhash].js",
    path: path.join(__dirname, "dist")
  },
  plugins: [
    new webpack.optimize.CommonsChunkPlugin({
      name: "runtime"
    })
  ]
}

webpack的文檔中說明，如果給webpack.optimize.CommonsChunkPlugin的name指定一個在entry中沒有聲明的名字，那么他會把runtime代碼打包到這個文件中，所以你這里可以任意指定你喜歡的name (ゝ??)b

那么現在打包出來會是神馬樣的呢？

app.aed80e077eb0a6c42e65.js    68 kB       0  [emitted]  app
runtime.ead626e4060b3a0ecb1f.js  5.82 kB       1  [emitted]  runtime
   [6] ./src/foo.js 55 bytes {0} [built]
    + 11 hidden modules

我們可以看到，app和runtime的hash是不一樣的。那么如果我們使用hash而不是chunkhash呢？

app.357eff03ae011d688ac3.js    68 kB       0  [emitted]  app
runtime.357eff03ae011d688ac3.js  5.81 kB       1  [emitted]  runtime
   [6] ./src/foo.js 55 bytes {0} [built]
    + 11 hidden modules

從這里就可以看出hash和chunkhash的區別了，chunkhash會包含每個chunk的區別（chunk可以理解為每個entry），而hash則是所有打包出來的文件都是一樣的，所以一旦你的打包輸出有多個文件，你勢必需要使用chunkhash。

類庫文件多帶帶打包

在一般的項目中，我們的類庫文件都不會經常更新，比如react，更多的時候我們更新的是業務代碼。那么我們肯定希望類庫代碼能夠盡可能長的在瀏覽器進行緩存，這就需要我們多帶帶給類庫文件打包了，怎么做呢？

修改配置文件：

module.exports = {
  entry: {
    app: path.join(__dirname, "src/foo.js"),
    vendor: ["react"]  // 所有類庫都可以在這里聲明
  },
  output: {
    filename: "[name].[chunkhash].js",
    path: path.join(__dirname, "dist")
  },
  plugins: [
    // 多帶帶打包，app中就不會出現類庫代碼
    // 必須放在runtime之前
    new webpack.optimize.CommonsChunkPlugin({
      name: "vendor",
    }),
    new webpack.optimize.CommonsChunkPlugin({
      name: "runtime"
    })
  ]
}

然后我們來執行以下打包：

 vendor.72d208b8e74b753cf09c.js    67.7 kB       0  [emitted]  vendor
    app.fdc2c0fe8694c1690cb3.js  494 bytes       1  [emitted]  app
runtime.035d95805255d39272ba.js    5.85 kB       2  [emitted]  runtime
   [7] ./src/foo.js 55 bytes {1} [built]
  [12] multi react 28 bytes {0} [built]
    + 11 hidden modules

vendor和app分開了，而且hash都不一樣，看上去很美好是不是？高興太早了年輕人。我們再新建一個文件，叫bar.js，代碼如下：

import React from "react"

export default function() {
  console.log(React.toString())
}

然后修改foo.js如下：

import bar from "./bar.js"
console.log(bar())

從這個修改中可以看出，我們并沒有修改類庫相關的內容，我們的vendor中應該依然只有react，那么vendor的hash應該是不會變的，那么結果如我們所愿嗎？

vendor.424ef301d6c78a447180.js    67.7 kB       0  [emitted]  vendor
    app.0dfe0411d4a47ce89c61.js  845 bytes       1  [emitted]  app
runtime.e90ad557ba577934a75f.js    5.85 kB       2  [emitted]  runtime
   [7] ./src/foo.js 45 bytes {1} [built]
   [8] ./src/bar.js 88 bytes {1} [built]
  [13] multi react 28 bytes {0} [built]
    + 11 hidden modules

很遺憾，webpack狠狠打了我們的臉╮(╯_╰)╭

這是什么原因呢？這是因為我們多加入了一個文件，對于webpack來說就是多了一個模塊，默認情況下webpack的模塊都是以一個有序數列命名的，也就是[0,1,2....]，我們中途加了一個模塊導致每個模塊的順序變了，vendor里面的模塊的模塊id變了，所以hash也就變了。總結一下：

app變化是因為內容發生了變化

vendor變化時因為他的module.id發生了變化

runtime變化時因為它本身就是維護模塊依賴關系的

那么怎么解決呢？

NamedModulePlugin和HashedModuleIdsPlugin

這兩個plugin讓webpack不再使用數字給我們的模塊進行命名，這樣每個模塊都會有一個獨有的名字，也就不會出現增刪模塊導致模塊id變化引起最終的hash變化了。如何使用？

{
  plugins: [
    new webpack.NamedModulesPlugin(),
    // new webpack.HashedModuleIdsPlugin(),
    new webpack.optimize.CommonsChunkPlugin({
      name: "vendor",
    }),
    new webpack.optimize.CommonsChunkPlugin({
      name: "runtime"
    })
  ]
}

NamedModulePlugin一般用在開發時，能讓我們看到模塊的名字，可讀性更高，但是性能相對較差。HashedModuleIdsPlugin更建議在正式環境中使用。

我們來看一下使用這個插件后，兩次打包的結果，修改前：

 vendor.91148d0e2f4041ef2280.js      69 kB       0  [emitted]  vendor
    app.0228a43edf0a32a59426.js  551 bytes       1  [emitted]  app
runtime.8ed369e8c4ff541ad301.js    5.85 kB       2  [emitted]  runtime
[./src/foo.js] ./src/foo.js 56 bytes {1} [built]
   [0] multi react 28 bytes {0} [built]
    + 11 hidden modules

修改后：

 vendor.91148d0e2f4041ef2280.js      69 kB       0  [emitted]  vendor
    app.f64e232e4b6d6a59e617.js  917 bytes       1  [emitted]  app
runtime.c12d50e9a1902f12a9f4.js    5.85 kB       2  [emitted]  runtime
[./src/bar.js] ./src/bar.js 88 bytes {1} [built]
   [0] multi react 28 bytes {0} [built]
[./src/foo.js] ./src/foo.js 43 bytes {1} [built]
    + 11 hidden modules

可以看到vendor的hash沒有變化，HashedModuleIdsPlugin也是一樣的效果。貌似世界變得更和諧了d(`???)b，是嗎？哈哈，并不是！

async module

隨著我們的系統變得越來越大，模塊變得很多，如果所有模塊一次性打包到一起，那么首次加載就會變得很慢。這時候我們會考慮做異步加載，webpack原生支持異步加載，用起來很方便。

我們再創建一個js叫做async-bar.js，在foo.js中：

import("./async-bar").then(a => console.log(a))

打包：

      0.1415eebc42d74a3dc01d.js  131 bytes       0  [emitted]
 vendor.19a637337ab59d16fb34.js      69 kB       1  [emitted]  vendor
    app.f7e5ecde27458097680e.js    1.04 kB       2  [emitted]  app
runtime.c4caa7f9859faa94b02e.js    5.88 kB       3  [emitted]  runtime
[./src/async-bar.js] ./src/async-bar.js 32 bytes {0} [built]
[./src/bar.js] ./src/bar.js 88 bytes {2} [built]
   [0] multi react 28 bytes {1} [built]
[./src/foo.js] ./src/foo.js 92 bytes {2} [built]
    + 11 hidden modules

恩，這時候我們已經看到，我們的vendor變了，但是更可怕的還在后頭，我們再建了一個模塊叫async-baz.js，一樣的在foo.js引用：

import("./async-baz").then(a => console.log(a))

然后再打包：

      0.eb2218a5fc67e9cc73e4.js  131 bytes       0  [emitted]
      1.61c2f5620a41b50b31eb.js  131 bytes       1  [emitted]
 vendor.1eada47dd979599cc3e5.js      69 kB       2  [emitted]  vendor
    app.1f82033832b8a5dd6e3b.js    1.17 kB       3  [emitted]  app
runtime.615d429d080c11c1979f.js     5.9 kB       4  [emitted]  runtime
[./src/async-bar.js] ./src/async-bar.js 32 bytes {1} [built]
[./src/async-baz.js] ./src/async-baz.js 32 bytes {0} [built]
[./src/bar.js] ./src/bar.js 88 bytes {3} [built]
   [0] multi react 28 bytes {2} [built]
[./src/foo.js] ./src/foo.js 140 bytes {3} [built]
    + 11 hidden modules

恩，我能說臟話嗎？不能？(╯‵□′)╯︵┻━┻

為啥每個模塊的hash都變了啊？！！為啥模塊又變成數字ID了啊？！！

好吧，言歸正傳，決絕辦法還是有的，那就是NamedChunksPlugin，之前是用來處理每個chunk名字的，似乎在最新的版本中不需要這個也能正常打包普通模塊的名字。但是這里我們可以用來處理異步模塊的名字，在webpack的plugins中加入如下代碼：

new webpack.NamedChunksPlugin((chunk) => { 
  if (chunk.name) { 
    return chunk.name; 
  } 
  return chunk.mapModules(m => path.relative(m.context, m.request)).join("_"); 
}),

再執行打包，兩次結果如下：

         app.5faeebb6da84bedaac0a.js    1.11 kB           app  [emitted]  app
async-bar.js.457b1711c7e8c6b6914c.js  144 bytes  async-bar.js  [emitted]
     runtime.f263e4cd58ad7b17a4bf.js     5.9 kB       runtime  [emitted]  runtime
      vendor.05493d3691191b049e65.js      69 kB        vendor  [emitted]  vendor
[./src/async-bar.js] ./src/async-bar.js 32 bytes {async-bar.js} [built]
[./src/bar.js] ./src/bar.js 88 bytes {app} [built]
   [0] multi react 28 bytes {vendor} [built]
[./src/foo.js] ./src/foo.js 143 bytes {app} [built]
    + 11 hidden modules


         app.55e3f40adacf95864a96.js     1.2 kB           app  [emitted]  app
async-bar.js.457b1711c7e8c6b6914c.js  144 bytes  async-bar.js  [emitted]
async-baz.js.a85440cf862a8ad3a984.js  144 bytes  async-baz.js  [emitted]
     runtime.deeb657e46f5f7c0da42.js    5.94 kB       runtime  [emitted]  runtime
      vendor.05493d3691191b049e65.js      69 kB        vendor  [emitted]  vendor
[./src/async-bar.js] ./src/async-bar.js 32 bytes {async-bar.js} [built]
[./src/async-baz.js] ./src/async-baz.js 32 bytes {async-baz.js} [built]
[./src/bar.js] ./src/bar.js 88 bytes {app} [built]
   [0] multi react 28 bytes {vendor} [built]
[./src/foo.js] ./src/foo.js 140 bytes {app} [built]
    + 11 hidden modules

可以看到結果都是用名字而不是id了，而且不改改變的地方也都沒有改變

注意生成chunk名字的邏輯代碼你可以根據自己的需求去改

使用上面的方式會有一些問題，比如使用.vue文件開發模式，m.request是一大串vue-loader生成的代碼，所以打包會報錯。當然大家可以自己找對應的命名方式，在這里我推薦一個webpack原生支持的方式，在使用import的時候，寫如下注釋：

import(/* webpackChunkName: "views-home" */ "../views/Home")

然后配置文件只要使用new NamedChunksPlugin()就可以了，不需要自己再拼寫名字，因為這個時候我們的異步chunk已經有名字了。

所以到這就結束了是嗎？真的，求你快結束吧，我想去吃我兩小時前買的烤鴨了。

好~~~的吧，我們還得搞點事情

增加更多的entry

修改webpack.config.js：

{
  ...
  entry: {
    app: path.join(__dirname, "src/foo.js"),
    vendor: ["react"],
    two: path.join(__dirname, "src/foo-two.js")
  },
  ...
}

增加的enrty如下：

import bar from "./bar.js"
console.log(bar)

import("./async-bar").then(a => console.log(a))
// import("./async-baz").then(a => console.log(a))

是的跟foo.js一模一樣，當然你可以改邏輯，只需要記得引用bar.js就可以。

然后我們打包，結果會讓你想再次(╯‵□′)╯︵┻━┻

         app.77b13a56bbc0579ca35c.js  612 bytes           app  [emitted]  app
async-bar.js.457b1711c7e8c6b6914c.js  144 bytes  async-bar.js  [emitted]
     runtime.bbe8e813f5e886e7134a.js    5.93 kB       runtime  [emitted]  runtime
         two.9e4ce5a54b4f73b2ed60.js  620 bytes           two  [emitted]  two
      vendor.8ad1e07bfa18dd78ad0f.js    69.5 kB        vendor  [emitted]  vendor
[./src/async-bar.js] ./src/async-bar.js 32 bytes {async-bar.js} [built]
[./src/bar.js] ./src/bar.js 88 bytes {vendor} [built]
   [0] multi react 28 bytes {vendor} [built]
[./src/foo-two.js] ./src/foo-two.js 143 bytes {two} [built]
[./src/foo.js] ./src/foo.js 143 bytes {app} [built]
    + 11 hidden modules

為毛所有文件的hash都變化了啊？！！！逗我玩呢？

好吧，原因是vendor作為common chunk并不只是包含我們在entry中聲明的部分，他還會包含每個entry中引用的公共代碼，有些時候你可能希望這樣的結果，但在我們這里，這就是我要解決的一個問題啊?(?д??)

所以這里怎么做呢，在CommonsChunkPlugin里面有一個參數，可以用來告訴webpack我們的vendor真的只想包含我們聲明的內容：

{
  plugins: [
    ...
    new webpack.optimize.CommonsChunkPlugin({
      name: "vendor",
      minChunks: Infinity
    }),
  ]
}

這個參數的意思是盡可能少的把公用代碼包含到vendor里面。于是我們又打包：

         app.5faeebb6da84bedaac0a.js    1.13 kB           app  [emitted]  app
async-bar.js.457b1711c7e8c6b6914c.js  144 bytes  async-bar.js  [emitted]
     runtime.b0406822caa4d1898cb8.js    5.93 kB       runtime  [emitted]  runtime
         two.9be2d4a28265bfc9d947.js    1.13 kB           two  [emitted]  two
      vendor.05493d3691191b049e65.js      69 kB        vendor  [emitted]  vendor
[./src/async-bar.js] ./src/async-bar.js 32 bytes {async-bar.js} [built]
[./src/bar.js] ./src/bar.js 88 bytes {app} {two} [built]
   [0] multi react 28 bytes {vendor} [built]
[./src/foo-two.js] ./src/foo-two.js 143 bytes {two} [built]
[./src/foo.js] ./src/foo.js 143 bytes {app} [built]
    + 11 hidden modules

恩，熟悉的味道。

到這里我們跟webpack的hash變化之戰算是告一段落，大部分webpack打包出現問題的原因是模塊命名的問題，所以解決辦法其實也就是給每個模塊一個固定的名字。

最后我們的配置如下：

const path = require("path")
const webpack = require("webpack")

module.exports = {
  entry: {
    app: path.join(__dirname, "src/foo.js"),
    vendor: ["react"],
    two: path.join(__dirname, "src/foo-two.js")
  },
  externals: {
    jquery: "jQuery"
  },
  output: {
    filename: "[name].[chunkhash].js",
    path: path.join(__dirname, "dist")
  },
  plugins: [
    new webpack.NamedChunksPlugin((chunk) => { 
      if (chunk.name) { 
        return chunk.name; 
      } 
      return chunk.mapModules(m => path.relative(m.context, m.request)).join("_"); 
    }),
    new webpack.NamedModulesPlugin(),
    // new webpack.HashedModuleIdsPlugin(),
    new webpack.optimize.CommonsChunkPlugin({
      name: "vendor",
      minChunks: Infinity
    }),
    new webpack.optimize.CommonsChunkPlugin({
      name: "runtime"
    })
  ]
}

如果你遇到了其他問題，你可以給我留言，我會去嘗試解決，希望大家看完能有一些收獲( σ?? ?)σ

參考文章：

https://webpack.js.org/guides/caching/

一篇牛逼的blog

云服務器 GPU云服務器你應該知道你知道數據分析知道你百度一下你就知道了

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/61916.html

希望做瀏覽器長緩存？關于Webpack生成的Hash，你應該知道這些

摘要：之后的配置都是用作為生成因為要處理不同模塊的依賴關系，所以他內置了一個模板用來處理依賴關系后面稱為，這段因此也會被打包的我們最后里面。于是我們又打包恩，熟悉的味道。童鞋，你看到這篇文章的時候很可能你只是在找一篇webpack的配置文章教學，但是聽老哥說一句，別去搜什么startkit或者best practice文章，特別是中文的，如果你找到了，也記得看一下文章啥時候寫的，超過半年的...

alighters 2019-08-21 17:36 評論0 收藏0
深入理解 Webpack 打包分塊（上）

摘要：而一個哈希字符串就是根據文件內容產生的簽名，每當文件內容發生更改時，哈希串也就發生了更改，文件名也就隨之更改。很顯然這不是我們需要的，如果文件內容發生了更改，的打包文件的哈希應該發生變化，但是不應該。前言隨著前端代碼需要處理的業務越來越繁重，我們不得不面臨的一個問題是前端的代碼體積也變得越來越龐大。這造成無論是在調式還是在上線時都需要花長時間等待編譯完成，并且用戶也不得不花額外的時間和帶寬...

Rocko 2019-05-21 16:11 評論0 收藏0
前端優化 - 收藏集 - 掘金

摘要：雖然有著各種各樣的不同，但是相同的是，他們前端優化不完全指南前端掘金篇幅可能有點長，我想先聊一聊閱讀的方式，我希望你閱讀的時候，能夠把我當作你的競爭對手，你的夢想是超越我。如何提升頁面渲染效率 - 前端 - 掘金Web頁面的性能我們每天都會瀏覽很多的Web頁面，使用很多基于Web的應用。這些站點看起來既不一樣，用途也都各有不同，有在線視頻，Social Media，新聞，郵件客戶端...

VincentFF 2019-08-20 17:15 評論0 收藏0
webpack學習筆記

摘要：配置完成后就可以使用來打包代碼了。值得注意的是會刪除所有無作用代碼也就是說那些包裹在這些全局變量下的代碼塊都會被刪除這樣就能保證這些代碼不會因發布上線而泄露。默認會從項目的根目錄下引入這些文件。命令使用 npm install webpack -g 作為全局安裝, 在任意目錄使用 npm install webpack --save-dev 作為項目依賴安裝 np...

mylxsw 2019-08-21 10:36 評論0 收藏0
Webpack 最佳實踐總結(二)

摘要：默認做法是告訴瀏覽器這個文件的緩存時間，然后當文件內容被修改，則需要重命名該文件告訴瀏覽器需要重新下載和緩存，例如也能做類似的工作。上一篇介紹了 Webpack 優化項目的四種技巧，分別是通過 UglifyJS 插件實現對 JavaScript 文件的壓縮，css-loader 提供的壓縮功能，配置NODE_ENV可以進一步去掉無用代碼，tree-shaking幫助找到更多無用代碼 ...

Stardustsky 2019-08-21 12:03 評論0 收藏0