webpack4 配置解析和实战

摘要：特性比较热门的两大特性，零配置和速度快号称提速上限一般情况下，相比于低版本，场景下第三方依赖打包速度和场景下本地服务首次启动速度都得到显著提升零配置通过指定当前场景为开发模式还是生产模式，自动设置好当前场景的默认配置，用户即可马上使用，不需

webpack4比较热门的两大特性，零配置和速度快（号称提速上限98%）

一般情况下，webpack4相比于低版本，production场景下第三方依赖打包速度 和 development场景下本地服务首次启动速度 都得到显著提升

零配置
通过mode指定当前场景为开发模式还是生产模式，自动设置好当前场景的默认配置，用户即可马上使用，不需要多余的配置

打包速度快
打包速度之所以能得到显著提升，多亏了Optimization这个新增的选项，下文会说到

1.入口（entry）

是应用程序，或者说一个页面的起点入口，如果传递一个数组，那么数组的每一项都会执行
每个html页面都有一个入口起点
单页面应用（SPA）：一个入口
多页面应用（MPA ：多个入口

entry: {
  home: "./home.js",
  about: "./about.js",
  contact: "./contact.js"
}

如果entry的值是一个字符串，那么打包之后的chunk名即为默认的main
如果entry的值是一个对象，则每个key都会是chunk的名字，每个key对应的值都是入口起点

2.输出（output）

output的值必须为一个对象，至少包含下面两个属性

filename: webpack打包之后输出文件的路径
path: 决定了每个输出的bundle的名称(即打包后的文件名字)，这些bundle将写入到output.path指定的目录下

例如：
单入口

output: {
    path: "/dist",
    filename: "bundle.js"
}

这个配置将会在根目录的dist文件夹下输出打包后的bundle.js，这是单页面应用的配置

多入口

output: {
    path: "/dist",
    filename: "js/[name].js"
}

即在dist目录下的js文件夹中输出一系列的bundle

一个比较难理解的配置：ouput.publicPath

配置html中引用的静态资源的目录，在多数情况下，此选项的值为"/"

publicPath并不会对webpack打包文件后存放的目录有所影响，是对生成的html中应用的静态资源，比如图片，css和js文件的引用路径做对应的补足

对于按需加载或者加载外部资源来说，这个选项的值尤为重要，如果设置错误，加载资源的时候会返回404

3.模块加载器（loader）

loaders可以说是各种模块的转换器，可以用来预处理文件，解析和打包除javascript之外的任何静态资源

loader要下载才能配置使用，比如:
npm install --save-dev css-loader
npm install --save-dev ts-loader

然后在webpack的配置文件中，声明，css后缀的文件使用css-loader解析，ts后缀的文件使用ts-loader解析

module.exports = {
  module: {
    rules: [
      { test: /.css$/, use: "css-loader" },
      { test: /.ts$/, use: "ts-loader" }
    ]
  }
};

更多loader的配置：webpack loaders

4.插件（plugins）

plugins用于自定义webpack的构建过程, 比如自定义打包之后的html模板，自定义js和样式文件是否打包等等
plugins的值，是一个个new出来的插件实例

webpack4取消了四个常用的用于性能优化的pluginUglifyjsWebpackPlugin，CommonsChunkPlugin，ModuleConcatenationPlugin，NoEmitOnErrorsPlugin
转而提供了一个名为optimization的配置项，用于替代以上四个插件（并不是说以上插件不能使用了，只是webpack4本身有替代的方案，可以不用插件）

html-webpack-plugin
通过new 该插件的实例，可以让webpack帮我们编译出一个html文件
需要注意的是，多页面的配置下，有多少个页面，就要new多少个实例，传入到plugins中，后面有代码示例。

html-webpack-inline-source-plugin
这个插件用于生产模式下，让webpack在打包的时候，将js和css直接插入到html中，从而减少请求的消耗
要注意的是，并不是所有情况下都适合用，文件较大时，还是推荐通过标签去引入资源（运行时文件一般比较小，下面会通过另一个插件将runtime的代码直接插入html中）

更多插件及其配置：webpack plugins

5.模式（mode）

mode是webpack4新增的参数选项，它有三个值，development、production、none,
由于开发模式和生产模式所需要的webpack的配置稍微有单不同（但是大部分是相同的）
所以可以建立两个webpack的配置文件，分别用于开发模式和生产模式，除此之外，指明当前处于哪个模式下，有利于webpack内部做优化
比如，有一些插件是在生产模式下才启用的。

通过指定mode的值为development和production中的一个，来表示webpack处于何种模式下，默认值是production

mode为 development 时，注重提升代码的构建速度和开发体验

module.exports = {
  mode: "development",
  cache: true,
  devtools: "eval",
  plugins: [
    new webpack.NamedModulesPlugin(),
    new webpack.DefinePlugin({ "process.env.NODE_ENV": JSON.stringify("development") })
  ]
};

mode为 production 时，提供代码优化，如压缩、作用域提升等

module.exports = {
  mode: "production",
  plugins: [
    new UglifyJsPlugin(/* ... */),
    new webpack.DefinePlugin({
        "process.env.NODE_ENV": JSON.stringify("production")
    }),
    new webpack.optimize.ModuleConcatenationPlugin(),
    new webpack.NoEmitOnErrorsPlugin()
  ]
}
 

也可以通过命令行运行下面的命令来指定模式
webpack --mode=production

6.优化（optimization）

这个选项也是wepack4新增的，主要用来自定义一些优化打包的策略

minimizer
在production模式下，该配置会默认为我们压缩混淆代码，但配置项过于少导致无法满足我们对于优化代码的诉求，下面是一套比较灵活的优化配置

var UglifyJsPlugin = require("uglifyjs-webpack-plugin")
var OptimizeCssAssetsPlugin = require("optimize-css-assets-webpack-plugin")
module.exports = {
  optimization: {
    minimizer: [
      // 自定义js优化配置，将会覆盖默认配置
      new UglifyJsPlugin({
        exclude: /.min.js$/, // 过滤掉以".min.js"结尾的文件，我们认为这个后缀本身就是已经压缩好的代码，没必要进行二次压缩
        cache: true,
        parallel: true, // 开启并行压缩，充分利用cpu
        sourceMap: false,
        extractComments: false, // 移除注释
        uglifyOptions: {
          compress: {
            unused: true,
            warnings: false,
            drop_debugger: true
          },
          output: {
            comments: false
          }
        }
      }),
      // 用于优化css文件
      new OptimizeCssAssetsPlugin({
        assetNameRegExp: /.css$/g,
        cssProcessorOptions: {
          safe: true,
          autoprefixer: { disable: true }, //这里注意下!!!!!
          mergeLonghand: false,
          discardComments: {
            removeAll: true // 移除注释
          }
        },
        canPrint: true
      })
    ]
  }
}

UglifyJsPlugin是大家经常使用的插件，这里比较亮的地方是可以过滤本身已经压缩的js，可以提升打包速度，并且避免二次混淆压缩造成的未知bug

OptimizeCssAssetsPlugin用来优化css文件的输出，优化策略包括：摈弃重复的样式定义、砍掉样式规则中多余的参数、移除不需要的浏览器前缀等
这里注意插件的参数autoprefixer: { disable: true }，一定要指定为true。否则的话该插件会把我们用autoprefix加好的前缀都移除掉（因为该插件觉得多余）

runtimeChunk
分离出webpack编译出来的运行时代码，也就是我们之前成为manifest的代码块，方便我们做文件的之就好缓存
这个参数项（runtimeChunk）有多种类型的值，其中，single即将所有的chunk的运行时代码打包到一个文件中，multiple即针对每个chunk的运行时代码分别打包出一个runtime文件
我们可以配合上面说到的 InlineManifestWebpackPlugin插件，将运行时代码直接插入html文件中，因为这段代码非常少，这样做可以避免一次请求的开销
InlineManifestWebpackPlugin插件的顺序一定要在HtmlWebpackPlugin之后，否则会导致编译失败

var HtmlWebpackPlugin = require("html-webpack-plugin")
var InlineManifestWebpackPlugin = require("inline-manifest-webpack-plugin")
module.exports = {
  optimization: {
    runtimeChunk: "single"
    // 等价于
    // runtimeChunk: {
    //   name: "runtime"
    // }
  },
  plugins: [
     new HtmlWebpackPlugin({
       template: "../src/index.html",
       filename: "article.html",
       chunks: ["article", "vendors", "runtime"]
     }),
     new InlineManifestWebpackPlugin(), //放在htmlWebpackPlugin的后面才能生效
  ]
}

splitChunks
这是比较难理解的一个配置项
webpack4移除了CommonsChunkPlugin插件，取而代之的是splitChunks
比较优雅的分离打包配置如下

splitChunks: {
  cacheGroups: {
    vendors: {
      test: /[/]node_modules[/]/,
      name: "vendors",
      minSize: 30000,
      minChunks: 1,
      chunks: "initial",
      priority: 1 // 该配置项是设置处理的优先级，数值越大越优先处理
    },
    commons: {
      test: /[/]src[/]common[/]/,
      name: "commons",
      minSize: 30000,
      minChunks: 3,
      chunks: "initial",
      priority: -1,
      reuseExistingChunk: true // 这个配置允许我们使用已经存在的代码块
    }
  }
}

这段配置，首先是将node_modules中的模块统一打包成vendors.js
它限制了分离文件的最小体积为30k（压缩之前的），因为webpack认为，小于30k的代码分离出来，还要额外小号一次请求去加载它，成本太高，这个值是通过大量的时间总结出来的
其次，还分离除了共享模块，比如src目录下有几个全局公用的js文件如utils等，可以多带带抽出来打包成一个commons.js
由于这部分文件不经常改变，有利于持久缓存

完：demo地址