国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

希望做瀏覽器長緩存？關(guān)于Webpack生成的Hash，你應(yīng)該知道這些

stefan / 1412人閱讀

摘要：之后的配置都是用作為生成因?yàn)橐幚聿煌K的依賴關(guān)系，所以他內(nèi)置了一個(gè)模板用來處理依賴關(guān)系后面稱為，這段因此也會被打包的我們最后里面。于是我們又打包恩，熟悉的味道。

童鞋，你看到這篇文章的時(shí)候很可能你只是在找一篇webpack的配置文章教學(xué)，但是聽老哥說一句，別去搜什么startkit或者best practice文章，特別是中文的，如果你找到了，也記得看一下文章啥時(shí)候?qū)懙模^半年的文章就別看了，百分之92.6里面的內(nèi)容已經(jīng)過期了。你想學(xué)webpack相關(guān)的姿勢，最好的辦法就是：看文檔

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

基本

首先我們弄一個(gè)最簡單的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

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

hash vs chunkhash

因?yàn)閣ebpack要處理不同模塊的依賴關(guān)系，所以他內(nèi)置了一個(gè)js模板用來處理依賴關(guān)系（后面稱為runtime），這段js因此也會被打包的我們最后bundle里面。在實(shí)際項(xiàng)目中我們常常需要將這部分代碼分離出來，比如我們要把類庫分開打包的情況，如果不多帶帶給runtime多帶帶生成一個(gè)js，那么他會和類庫一起打包，而這部分代碼會隨著業(yè)務(wù)代碼改變而改變，導(dǎo)致類庫的hash也每次都改變，那么我們分離出類庫就沒有意義了。所以這里我們需要給runtime多帶帶提供一個(gè)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指定一個(gè)在entry中沒有聲明的名字，那么他會把runtime代碼打包到這個(gè)文件中，所以你這里可以任意指定你喜歡的name (ゝ??)b

那么現(xiàn)在打包出來會是神馬樣的呢？

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的區(qū)別了，chunkhash會包含每個(gè)chunk的區(qū)別（chunk可以理解為每個(gè)entry），而hash則是所有打包出來的文件都是一樣的，所以一旦你的打包輸出有多個(gè)文件，你勢必需要使用chunkhash。

類庫文件多帶帶打包

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

修改配置文件：

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

然后我們來執(zhí)行以下打包：

 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都不一樣，看上去很美好是不是？高興太早了年輕人。我們再新建一個(gè)文件，叫bar.js，代碼如下：

import React from "react"

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

然后修改foo.js如下：

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

從這個(gè)修改中可以看出，我們并沒有修改類庫相關(guān)的內(nèi)容，我們的vendor中應(yīng)該依然只有react，那么vendor的hash應(yīng)該是不會變的，那么結(jié)果如我們所愿嗎？

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狠狠打了我們的臉╮(╯_╰)╭

這是什么原因呢？這是因?yàn)槲覀兌嗉尤肓艘粋€(gè)文件，對于webpack來說就是多了一個(gè)模塊，默認(rèn)情況下webpack的模塊都是以一個(gè)有序數(shù)列命名的，也就是[0,1,2....]，我們中途加了一個(gè)模塊導(dǎo)致每個(gè)模塊的順序變了，vendor里面的模塊的模塊id變了，所以hash也就變了。總結(jié)一下：

app變化是因?yàn)閮?nèi)容發(fā)生了變化

vendor變化時(shí)因?yàn)樗膍odule.id發(fā)生了變化

runtime變化時(shí)因?yàn)樗旧砭褪蔷S護(hù)模塊依賴關(guān)系的

那么怎么解決呢？

NamedModulePlugin和HashedModuleIdsPlugin

這兩個(gè)plugin讓webpack不再使用數(shù)字給我們的模塊進(jìn)行命名，這樣每個(gè)模塊都會有一個(gè)獨(dú)有的名字，也就不會出現(xiàn)增刪模塊導(dǎo)致模塊id變化引起最終的hash變化了。如何使用？

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

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

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

 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

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

我們再創(chuàng)建一個(gè)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

恩，這時(shí)候我們已經(jīng)看到，我們的vendor變了，但是更可怕的還在后頭，我們再建了一個(gè)模塊叫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

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

為啥每個(gè)模塊的hash都變了啊？！！為啥模塊又變成數(shù)字ID了啊？！！

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

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

再執(zhí)行打包，兩次結(jié)果如下：

         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

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

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

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

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

然后配置文件只要使用new NamedChunksPlugin()就可以了，不需要自己再拼寫名字，因?yàn)檫@個(gè)時(shí)候我們的異步chunk已經(jīng)有名字了。

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

好~~~的吧，我們還得搞點(diǎn)事情

增加更多的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一模一樣，當(dāng)然你可以改邏輯，只需要記得引用bar.js就可以。

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

         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中聲明的部分，他還會包含每個(gè)entry中引用的公共代碼，有些時(shí)候你可能希望這樣的結(jié)果，但在我們這里，這就是我要解決的一個(gè)問題啊?(?д??)

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

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

這個(gè)參數(shù)的意思是盡可能少的把公用代碼包含到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變化之戰(zhàn)算是告一段落，大部分webpack打包出現(xiàn)問題的原因是模塊命名的問題，所以解決辦法其實(shí)也就是給每個(gè)模塊一個(gè)固定的名字。

最后我們的配置如下：

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

文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/61916.html

相關(guān)文章

  • 希望做瀏覽器長緩存？關(guān)于Webpack生成的Hash，你應(yīng)該知道這些

    摘要：之后的配置都是用作為生成因?yàn)橐幚聿煌K的依賴關(guān)系，所以他內(nèi)置了一個(gè)模板用來處理依賴關(guān)系后面稱為，這段因此也會被打包的我們最后里面。于是我們又打包恩，熟悉的味道。 童鞋，你看到這篇文章的時(shí)候很可能你只是在找一篇webpack的配置文章教學(xué)，但是聽老哥說一句，別去搜什么startkit或者best practice文章，特別是中文的，如果你找到了，也記得看一下文章啥時(shí)候?qū)懙模^半年的...

    alighters 評論0 收藏0

  • 深入理解 Webpack 打包分塊（上）

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

    Rocko 評論0 收藏0

  • 前端優(yōu)化 - 收藏集 - 掘金

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

    VincentFF 評論0 收藏0

  • webpack學(xué)習(xí)筆記

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

    mylxsw 評論0 收藏0

  • Webpack 最佳實(shí)踐總結(jié)(二)

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

    Stardustsky 評論0 收藏0

發(fā)表評論

0條評論

最新活動
閱讀需要支付1元查看
<