vue-cli之webpack3構建全面提速優化

前言

伴隨着vue的全球化，各類vue的組件框架愈來愈完善，從早期的element-ui到vux，iview等愈來愈多高質量的項目，使用vue進行前端構建已然是一件工程化，模塊化，敏捷化的事情

在這其中，相信不少人都會選擇官方的vue-cli初始化工程模板，而後經過引入第三方組件框架和工具的方式進行開發構建，我我的也十分推崇這種作法。可是vue-cli初始化的項目模板畢竟是面向全部開發者的，在兼容性方面會有必定妥協。相信不少人都已經搜索過各種的webpack構建優化文章，可是不少不是版本太老就是不嚴謹 本文但願能在耗時優化與構建性能提高之間作一個平衡，即花最少的時間，對官方模板作最少的修改下，賺取最大的構建性能提高

思路

早期版本的vue-cli和webpack2時代，網上流傳如下優化配置，但其實新版本的vue-cli和webpack3已經不須要

• 使用ParallelUglifyPlugin替換UglifyPlugin（新版本的UglifyPlugin已經支持且默認開啓了多線程並行構建，因此此步驟沒有必要）

• 啓用webpack3的Scope Hoisting（vue-cli新版本已經配置webapck3，且已經默認開啓此配置）

• 善用alias（新版本vue-cli已經進行此項工做）

• 配置CommonsChunkPlugin提取公用代碼（新版本vue-cli已經進行此項工做）

對於新版本的vue-cli和webpack3，如下簡單配置優化後可提高最少2倍的構建速度

1. 按需引用
2. 啓用happypack多核構建項目
3. 修改source-map配置
4. 啓用DllPlugin和DllReferencePlugin預編譯庫文件

實踐

一、按需引用

1.1 幾乎全部的第三方組件框架都會提供組件的按需引用方式，以iview爲例，經過藉助插件babel-plugin-import能夠實現按需加載組件，減小文件體積，只須要修改.babelrc文件

npm install babel-plugin-import --save-dev

// .babelrc
{
  "plugins": [["import", {
    "libraryName": "iview",
    "libraryDirectory": "src/components"
  }]]
}
複製代碼

1.2 而後這樣按需引入組件，就能夠減少體積了

import { Button } from 'iview'
Vue.component('Table', Table)
複製代碼

二、啓用happypack多核構建項目

安裝happypack後，修改/build/webpack.base.conf.js文件便可

npm install happypack --save-dev

// /build/webpack.base.conf.js
const HappyPack = require('happypack')
const os = require('os')
const happyThreadPool = HappyPack.ThreadPool({ size: os.cpus().length })
// 增長HappyPack插件
plugins: [
    new HappyPack({
      id: 'happy-babel-js',
      loaders: ['babel-loader?cacheDirectory=true'],
      threadPool: happyThreadPool,
    })
  ]
// 修改引入loader
{
    test: /\.js$/,
    // loader: 'babel-loader',
    loader: 'happypack/loader?id=happy-babel-js', // 增長新的HappyPack構建loader
    include: [resolve('src'), resolve('test')]
}
複製代碼

三、修改source-map配置

3.1 首先修改/config/index.js文件

// /config/index.js
dev環境：devtool: 'eval'（最快速度）
prod環境：productionSourceMap: false（關閉source-map）
複製代碼

3.2 而後修改/src/main.js文件，關閉生產環境的調試信息

// /src/main.js
const isDebug_mode = process.env.NODE_ENV !== 'production'
Vue.config.debug = isDebug_mode
Vue.config.devtools = isDebug_mode
Vue.config.productionTip = isDebug_mode
複製代碼

四、啓用DllPlugin和DllReferencePlugin預編譯庫文件

這是最複雜也是提高效果最明顯的一步，原理是將第三方庫文件單獨編譯打包一次，之後的構建都不須要再編譯打包第三方庫

4.1 增長build/webpack.dll.config.js文件，並在其中配置須要單獨DLL化的模塊

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

module.exports = {
  // 你想要打包的模塊的數組
  entry: {
    vendor: ['vue/dist/vue.esm.js', 'axios', 'vue-router', 'iview']
  },
  output: {
    path: path.join(__dirname, '../static/js'), // 打包後文件輸出的位置
    filename: '[name].dll.js',
    library: '[name]_library'
  },
  plugins: [
    new webpack.DllPlugin({
      path: path.join(__dirname, '.', '[name]-manifest.json'),
      name: '[name]_library',
      context: __dirname
    }),
    // 壓縮打包的文件
    new webpack.optimize.UglifyJsPlugin({
      compress: {
        warnings: false
      }
    })
  ]
}
複製代碼

4.2 在build/webpack.dev.conf.js 和 build/webpack.prod.conf.js 增長以下插件

new webpack.DllReferencePlugin({
    context: __dirname,
    manifest: require('./vendor-manifest.json')
})
複製代碼

4.3 在/package.json增長命令

"dll": "webpack --config ./build/webpack.dll.config.js"
複製代碼

4.4 在/index.html增長DLL化JS引入（必須首先引入）

<script src="/static/js/vendor.dll.js"></script>
複製代碼

4.5 執行構建

npm run dll（這一步會生成build/vendor-manifest.json和static/js/vendor.dll.js）
npm run dev 或 npm run build
複製代碼

後記

以上四個大步驟完成後，咱們就完成了對vue-cli模板工程構建優化提高，雖然看起來依然算不上簡單，可是這已是最最最簡單的優化了，還有更多奇技淫巧沒有展開，由於我以爲過多的優化配置意義不大，反而會給項目工程帶來太多冗餘和複雜化

以上的配置實際測試的構建效果是從原先的13秒減小到了6秒左右，熱部署更是毫秒級的

最重要的是，最簡單化的配置，在將來vue-cli和webpack升級新版本後，也能夠很容易的從新配置進去使用，熟練配置一次後，從新再還原配置只須要5分鐘左右想一想花5分鐘修改一下配置，就能換來每次構建2倍以上速度的提高，是否是會有點小激動呢：）

再多說些後話吧，其實webpack2至webpack3的升級，我的以爲蠻失望的，由於它仍是沒有從根本上解決其配置過於複雜的問題，做爲目標是佔領全世界全部web項目構建的產品，它應該更多地從易用性/人性化的角度去考慮 每一次看着webpack的工程裏面的各類.babelrc，.postcssrc.js...還有各類的.conf文件，甚至還有各類的main，index，app文件，就忍不住想吐槽，究竟爲何前端的構建會發展成這樣，一個好好的項目工程裏，十幾種配置文件，真的有必要嗎？我本來覺得webpack3會將這一切變得簡單，然而它並無，不過既然暫時沒有辦法去改變，那咱們能作的就是，儘量理解其中原理，盡本身最大的可能去簡化/優化

後續...

這篇文章開始動筆的時候仍是2017年的年底，關於【後記】中的思考和討論，其實在2018年已經有了比較完美的解決方案，那就是 parcel ，雖然國內搜索關於它的資料還很少，可是從目前來看，這幾乎是前端構建最完美和最終極的解決方案。針對webpack配置過於冗餘複雜，且代碼侵入強的問題，parcel採用的是徹底零配置的構建方案。雖然我我的並不是專職於前端工做，可是前端也是我很大的興趣愛好之一，對於前端最前沿的成果必定是要去嘗試的 對於parcel的嘗試，讓我深陷其中，以致於到目前爲止，我已經將我我的全部的前端項目不管大小，所有切換成parcel構建，而完全放棄webpack。目前我將parcel和vue結合的模板工程項目開源 Parcel-VUE Github & Parcel-VUE官網，但願能借此幫助到更多被webpack困擾或者是被複雜的構建阻撓在前端學習之門外的讀者們

感謝你的閱讀，但願本文可以給你帶來幫助：）

做者：CheneyXu 關於：XServer官網