vue-cli 打包优化

随着项目越来越大,打包的速度也变的很慢,甚至出现了node内存溢出,今天来一起学习一下打包的一些优化

node内存溢出

有些时候,打包或者编译会报这个错误: FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed

是因为Node是基于V8引擎,我们的64位电脑只能支持到1.4G的内存,超过这个就会报错,解决方法如下

cnpm install -g increase-memory-limit 全局安装increase-memory-limit

进入项目文件夹,运行：increase-memory-limit

如果还是不行,在packjson中修改build命令

"build": "node --max_old_space_size=8192 build/build.js"

如果是多人合作的项目,也可以直接将increase-memory-limit配置到文件当中,做法如下

npm install increase-memory-limit -S
npm install cross-env -S

在packjson中添加命令"fix-memory-limit": "cross-env LIMIT=8192 increase-memory-limit"

直接运行 npm run fix-memory-limit 就可以了

可以在/node_modules/.bin/文件中看到,文件被修改了运行内存

使用HappyPack多进程进行loader处理

优化原理:

由于运行在 Node.js 之上的 Webpack 是单线程模型的,所以 Webpack 需要处理的事情只能一件一件地做,不能多件事一起做。
而 HappyPack 的处理思路是：将原有的 webpack 对 loader 的执行过程,从单一进程的形式扩展多进程模式,从而加速代码构建。

cnpm i happypack -S 安装插件

修改build/webpack.base.conf.js 文件

const HappyPack = require('happypack');
// node 提供的系统操作模块
const os = require('os');
// 根据我的系统的内核BS数量 指定BS线程池个数 也可以其他数量
const happyThreadPool = HappyPack.ThreadPool({ size: os.cpus().length });
 
module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        //把对.js 的文件处理交给id为happyBabel 的HappyPack 的实例执行
        loader: 'happypack/loader?id=happyBabel',
        include: [resolve('src')],
        //排除node_modules 目录下的文件
        exclude: /node_modules/
      },
    ]
  },
  plugins: [
    new HappyPack({
        //用id来标识 happypack处理那里类文件
      id: 'happyBabel',
      //如何处理  用法和loader 的配置一样
      loaders: [{
        loader: 'babel-loader?cacheDirectory=true',
      }],
      //共享进程池
      threadPool: happyThreadPool,
      //允许 HappyPack 输出日志
      verbose: true,
    })
  ]
}

如果报错的话,说明当前使用的webpack版本没有自带os,需要自己安装

npm i webpack-parallel-uglify-plugin -D
npm i os -D

配置loader的 include & exclude

优化原理

webpack 的 loaders 里的每个子项都可以有 include 和 exclude 属性：
- include：导入的文件将由加载程序转换的路径或文件数组（把要处理的目录包括进来）
- exclude：不能满足的条件（排除不处理的目录）
我们可以使用 include 更精确地指定要处理的目录，这可以减少不必要的遍历，从而减少性能损失。
同时使用 exclude 对于已经明确知道的，不需要处理的目录，予以排除，从而进一步提升性能。

打开 build/webpack.base.conf.js 文件,添加如下 include , exclude 配置：

module: {
  rules: [
    {
      test: /.vue$/,
      loader: 'vue-loader',
      options: vueLoaderConfig,
      include: [resolve('src')],  // 添加配置
      exclude: /node_modules(?!(autotrack|dom-utils))|vendor.dll.js/ // 添加配置
    },
    {
      test: /.js$/,
      loader: 'babel-loader',
      include: [resolve('src'), resolve('test'), resolve('node_modules/webpack-dev-server/client')], // 添加配置
      exclude: /node_modules/ // 添加配置
    }
  // ...
  ]
}

配置 resolve.modules

优化原理:

webpack 的 resolve.modules 是用来配置模块库（即 node_modules）所在的位置。当 js 里出现 import ‘vue’ 这样不是相对、也不是绝对路径的写法时,它便会到 node_modules 目录下去找。
在默认配置下,webpack 会采用向上递归搜索的方式去寻找。但通常项目目录里只有一个 node_modules,且是在项目根目录。为了减少搜索范围,可我们以直接写明 node_modules 的全路径。

修改build/webpack.base.conf.js 文件

module.exports = {
  resolve: {
    extensions: ['.js', '.vue', '.json'],
    modules: [
      resolve('src'),
      resolve('node_modules')
    ],
    alias: {
      'vue$': 'vue/dist/vue.esm.js',
      '@': resolve('src'),
    }
  }
  ...
}

查看打包后的文件体积

打包的时候 npm run build --report

使用webpack-parallel-uglify-plugin多线程压缩JS

优化原理:

默认情况下 webpack 使用 UglifyJS 插件进行代码压缩,但由于其采用单线程压缩,速度很慢。
我们可以改用 webpack-parallel-uglify-plugin 插件,它可以并行运行 UglifyJS 插件,从而更加充分、合理的使用 CPU 资源,从而大大减少构建时间。

npm i webpack-parallel-uglify-plugin 安装

修改build/webpack.prod.conf.js 文件

const ParallelUglifyPlugin = require('webpack-parallel-uglify-plugin');
// 删掉webpack提供的UglifyJS插件
//new UglifyJsPlugin({
//  uglifyOptions: {
//    compress: {
//      warnings: false
//    }
//  },
//  sourceMap: config.build.productionSourceMap,
//  parallel: true
//}),
// 增加 webpack-parallel-uglify-plugin来替换
  new ParallelUglifyPlugin({
    cacheDir: '.cache/',
    uglifyJS:{
      output: {
        comments: false
      },
      compress: {
        drop_debugger: true,
        drop_console: true,
        pure_funcs: ['console.log']
      },
      warnings: false
    }
  })

warnings 有一些webpack的版本是放在compress里面的

可能打包后会报错:

ERROR in Encountered an error while minifying static/js/vendor.js:
Maximum call stack size exceeded

不要紧,是因为vendor.js这个文件太大了,导致压缩失败,继续往下走,后面把第三方库抽离出来后就不会报错了

去除map文件,并开启gzip打包

cnpm install --save-dev compression-webpack-plugin@1.1.11安装,这里一定要带版本号安装,否则会报错

在config/index中修改

build: {
  productionSourceMap: false,
  productionGzip: true
}

dev中的配置也可以稍微修改一选

1	devtool: 'eval'(最快速度)

使用 DllPlugin 和 DllReferencePlugin 预编译资源模块

优化原理:

我们的项目依赖中通常会引用大量的 npm 包,而这些包在正常的开发过程中并不会进行修改,但是在每一次构建过程中却需要反复的将其解析,而下面介绍的两个插件就是用来规避此类损耗的：
- DllPlugin 插件：作用是预先编译一些模块。
- DllReferencePlugin 插件：它的所用则是把这些预先编译好的模块引用起来。
注意：DllPlugin 必须要在 DllReferencePlugin 执行前先执行一次,dll 这个概念应该也是借鉴了 windows 程序开发中的 dll 文件的设计理念。

实践:

新建一个配置文件，比如build/webpack.dll.conf.js

const path = require('path')
const webpack = require('webpack')
module.exports = {
  entry: {
    vendor: ['vue','vue-router','cs-ruler']
  },
  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 //必填，不然在web网页中找不到 '_dll_[name]'，会报错
    }),
    // 压缩打包的文件
    new webpack.optimize.UglifyJsPlugin({
      compress: {
        warnings: false
      }
    })
  ]
}

vendor里面就是第三方库

编辑 package.json 文件,添加一条编译命令

1	"dll": "webpack --config build/webpack.dll.conf.js"

npm run dll 成功以后，static下会有dll.vendor.js，根目录下会有vendor.manifest.json

ok，到这里，抽离依赖库的事情就完成了，那么接下来问题就是怎么引用呢，怎么在dev和build跑呢？

这里补了一点dll和commonsChunk概念上的区别，commonsChunk之所以慢和大，是因为每次run的时候，都会去做一次打包，而实际上我们不会一直去更新我们引用的依赖库，所以dll的做法就等于是，事先先打包好依赖库，然后只对每次都修改的js做打包。

好了,继续

修改build/webpack.dev.conf.js 和 build/webpack.prod.conf.js, 添加DllReferencePlugin的配置

const webpack = require('webpack');

//.....
plugins: [
  new webpack.DllReferencePlugin({
    context: __dirname,
    manifest: require('./vendor-manifest.json')
  })
]

最后再index.html中添加<script src="/static/js/vendor.dll.js"></script>

到这里,vue打包优化配置基本结束