nuxt升级到v2之后，终于可以使用webpack 4了，喜大普奔。新版本的webpack给构建项目提供更多的优化。具体的webpack 4 的介绍可以参看官网（ https://webpack.js.org/ ）。 这里主要介绍的是利用webpakc 4中的 splitChunks 优化nuxt build之后产生模块体积。

1. 问题背景

为了便于理解，我建立了一个简单的项目，下面是基本的配置文件 nuxt.config.js 。

module.exports = {
  ** Headers of the page
  head: {
    title: 'starter',
    meta: [
      { charset: 'utf-8' },
      { name: 'viewport', content: 'width=device-width, initial-scale=1' },
      { hid: 'description', name: 'description', content: 'Nuxt.js project' }
    link: [
      { rel: 'icon', type: 'image/x-icon', href: '/favicon.ico' },
      { rel: 'stylesheet', href: 'https://unpkg.com/element-ui/lib/theme-chalk/index.css'}
  apollo: {
    clientConfigs: {
      default: {
        httpEndpoint: 'http://localhost:4000',
  ** Global CSS
  css: ['~/assets/css/main.css'],
  plugins: ['~/plugins/vuetify.js', '~plugins/axios.js', '~/plugins/element-ui.js'],
  ** Add axios globally
  build: {
    analyze: true,
    ** Run ESLINT on save
    extend (config, ctx) {
      if (ctx.isDev && ctx.isClient) {
        config.module.rules.push({
          enforce: 'pre',
          test: /\.(js|vue)$/,
          loader: 'eslint-loader',
          exclude: /(node_modules)/
  modules: ['@nuxtjs/apollo']
 通过config文件，不难发现本项目需要的依赖包括vuetify, axios, element-ui, 还有@nuxtjs/apollo。这些模块，尤其是vuetify和element-ui都是体积比较大的模块。nuxt build之后，在.nuxt/dist目录下产生了client和server两个文件夹，分别包含了前后端需要的文件。下图是控制台输出的client中文件信息，

 在实际应用中，加载较大体积的资源耗费的时间也会相对较大，尤其在网速不给力的时候，会对页面性能造成很大的影响。因此，将这些模块拆分成更小的模块是非常必要的。

2. Nuxt基本打包原理
 Nuxt 2中是用webpack 4进行打包，对应的config文件都在template\node_modules\nuxt\lib\builder\webpack目录下。其中，base.js提供了webpack的基本配置，而client.js和server.js提供了打包前后端时的具体配置项。下面，我们来仔细研究client.js来推导vendors.app.js生成原理。在client.js中定义了入口文件。
 config.entry = {
      app: [path.resolve(this.options.buildDir, 'client.js')]
 最终直接打包出来的文件由四个部分组成，
runtime.js

commons.app.js

vendors.app.js

app.js
 除了runtime.js，其他文件名字中均包含app单词。之所以最后拆分成四个js文件，是因为nuxt 2中启用了webpack 4的splitChunks功能。顾名思义，就是把拆分模块。对应的源码如下，
optimization() {
    const optimization = super.optimization()
    // Small, known and common modules which are usually used project-wise
    // Sum of them may not be more than 244 KiB
      this.options.build.splitChunks.commons === true &&
      optimization.splitChunks.cacheGroups.commons === undefined
      optimization.splitChunks.cacheGroups.commons = {
        test: /node_modules[\\/](vue|vue-loader|vue-router|vuex|vue-meta|core-js|@babel\/runtime|axios|webpack|setimmediate|timers-browserify|process|regenerator-runtime|cookie|js-cookie|is-buffer|dotprop|nuxt\.js)[\\/]/,
        chunks: 'all',
        priority: 10,
        name: true
    return optimization
 上述源码表示开启了optimization的功能，其中还增加了一个cacheGroup，将符合test正则表达式的模块过滤出来，单独打包成common.app.js，而剩下的则是打包进了vendor.app.js。而这里的optimization是继承自base.js中的optimization配置，在进行进一步配置。追根溯源，最开始传入的配置都来源于template\node_modules\nuxt\lib\common\nuxt.config.js。事实上这里的nuxt.config.js提供了所有可能的配置，是很好的参考。这里我们重点关注关于optimization和splitChunks选项，对应代码如下。
export default {
  build: {
    optimization: {
      runtimeChunk: 'single',
      minimize: undefined,
      minimizer: undefined,
      splitChunks: {
        chunks: 'all',
        automaticNameDelimiter: '.',
        name: undefined,
        cacheGroups: {}
      splitChunks: {
        layouts: false,
        pages: true,
        commons: true
3. 配置nuxt.config.js以提取大体积模块
 因此，我们可以在自己项目中的nuxt.config.js中添加cacheGroups选项，将一些体积较大的模块过滤出来生成单独的文件。我在nuxt.config.js中增加了两个cacheGroups分别打包vuetify和element-ui。由于这两个的cacheGroups的priority是20，高于commons，所以某一模块即使符合commons的test的正则表达式，也会优先被打包进去vuetify或element-ui中。
build: {
    optimization: {
      splitChunks: {
        chunks: 'all',
        automaticNameDelimiter: '.',
        maxAsyncRequests: 7,
        cacheGroups: {
          vuetify: {
            test: /node_modules[\\/]vuetify/,
            chunks: 'all',
            priority: 20,
            name: true
          elementui: {
            test: /node_modules[\\/]element-ui/,
            chunks: 'all',
            priority: 20,
            name: true
 下面两张是修改后的nuxt.config.js下build出来的结果，