webpack4.0.0.beta尝鲜

date: 2018-03-19 16:01:31

标签（空格分隔）： webpack

近年来前端技术如雨后春笋蓬勃发展，我们也在不断学习中成长。例如：jsx 方便了我们在 js 中编写 html，less/sass 的出现提高了我们书写 css 的能力，AMD/CommonJS/ES6 的出现为我们模块化开发提供了便利。然而，我们需要使用其它工具将这些 工具 转化成原生语言以运行在浏览器上。但这样导致的问题就是代码体积越来越大，变的复杂不可控。于是，我们就开始考虑针对这些庞大的代码进行优化，webpack 就是这个需求下的产物。 webpack 可以看做是模块打包机。它做的事情是：分析你的项目结构，找到JavaScript模块以及其它的一些浏览器不能直接运行的拓展语言（Scss，TypeScript等），并将其打包为合适的格式以供浏览器使用。目前，webpack 总共发布了三个稳定版本。从17年八月底开始，经历了长达五个月的开发周期，webpack 团队通过增加大量新特性、bug修复、问题改善并于近期发布了 webpack4 的 beta 版本。如果你对 webpack 感兴趣，下面我们就来学习一下 webpack4 beta 的新特性。

P.S. 以下所有代码演示代码都是基于 webpack 4.0.0-beta.0

一、安装webpack v4.0.0-beta.0

如果你使用yarn yarn add webpack@next webpack-cli --dev 如果你使用npm npm install webpack@next webpack-cli --save-dev

二、webpack 4.0 新特性介绍

下面是一些你肯定会感兴趣的新特性。在阅读完本章之后，如果你觉得不过瘾，完整的修改列表请查看 官方修改日志 github.com/webpack/web…

本章将从以下几部分来介绍 webpack 4.0。

2.1 环境

webpack 运行环境升级。已经不支持 Node.js 4 版本。源码升级到更高的 ECMAScript 版本。

根据 webpack package.json 配置中显示 Node.js 最低支持版本："node": ">=6.11.5"

2.2 模块

webpack 模块类型及 .mjs 的支持：

长久以来，JS是webapck中唯一的模块类型。正因此，开发者无法有效地打包其它类型的文件。目前，webpack实现了五种模块类型，它们各有自己的优势，可按需要使用（后面会详细说明）。

javascript/auto
javascript/esm
javascript/dynamic
json
webassembly/experimental

用法： module.rules 中的 type 就是新增加的属性，用来支持不同的模块类型。

module: {
    rules: [{
      test: /\.special\.json$/,
      type: "javascript/auto",
      use: "special-loader"
    }]
  }
复制代码

此外，现在webpack 按照 .wasm, .mjs, .js, 以及 .json 等扩展名的顺序来解析。

javascript/esm 相比于 javascript/auto 处理ESM更加严格

我们说既然有了 javascript/auto 为什么还要细分那么多其他类型呢？这是因为每种类型都有自己独特的处理优势。具体表现在两个方面：

1. 导入的名称必须存在于导入的模块中。
2. 动态的模块（非ESM，例如CommonJS）只能通过默认 import 导入，其他所有（包括命名空间导入）的导入都会报错。

2.3 用法

• 必须在 “开发或者生产” 中选择一种模式（这里有一种隐藏模式 none ，可以禁用一切功能）。
  • 生产模式不支持监听，开发模式针对快速增量重建进行了优化。
  • 生产模式同样支持模块串联，即变量提升（此功能在webpack 3 中已经实现）。
  • 开发模式下支持注释和提示，并且支持 eval 的source map。
• 将 CLI 移动到 webpack-cli 中，你需要通过安装 webpack-cli 使用 CLI。
• 你可以使用 optimization.* 标志来配置自己的自定义模式。
• webpackInclude 和 webpackExclude 可以通过神奇的注释来支持 import() ，他们允许在使用动态表达式时过滤文件。
• 使用 System.import() 会发出警告:
  • 可以使用 Rule.parser.system: true 关闭警告。
  • 你也可以使用 Rule.parser.system: false 关闭 System.import() 。
• 对于迁移到新的插件系统的插件 ProgressPlugin 现在显示插件名称。
• webpack 现在可以本地处理 JSON。如果用 loader 转换 json 为 js，需要设置： type: "javascript/auto" 。当然，不用 loader webpack 依然可以正常工作。

2.4 配置

• 删除了一些常用内置插件：
  • NoEmitOnErrorsPlugin -> optimization.noEmitOnErrors (生产模式默认)
  • ModuleConcatenationPlugin -> optimization.concatenateModules （生产模式默认）
  • NamedModulesPlugin -> optimization.namedModules （开发模式默认）
  • **删除了常用的 CommonsChunkPlugin -> optimization.splitChunks **对于那些需要细粒度控制缓存策略的人，可以通过 optimization.splitChunks和optimization.runtimeChunk。
• 现在可以使用module.rules[].resolve来配置解析。它与全局配置合并
• optimization.minimize 用于控制minimizing的开关。
  • 生产模式默认为开，开发模式默认为关。
• optimization.minimizer 用于配置minimizers和选项。
• 许多支持占位符的配置选项现在也支持函数形式。
• 错误的 options.dependencies 配置现在会抛出异常。
• sideEffects 可以通过 module.rules 覆盖。
• 添加 output.globalObject 配置选项以允许在运行时选择全局对象引用。
• 无需显式设置entry和output属性，webpack默认设置entry属性为./src，output的属性为./dist。
• 移除module.loaders。

2.5 优化

sideEffects: false
optimization.splitChunks

以下是一些内部优化：

buildMeta.exportsType: "default"
Parser (parserStringArray, parserCalculatedStringArray)

2.6 性能

• 默认情况，UglifyJS 默认缓存和并行化（并未完全实现缓存和并行化，webpack5的里程碑）。
• 发布了一个新版本的插件系统，所以事件钩子和处理程序变的单一化。
• 多个性能改进，特别是更快的增量重建。
• 改进了RemoveParentModluesPlugin的性能。

2.7破坏性的改变（插件、loader相关）

• 新的插件系统

  Compiler.hooks.xxx.tap(<plugin name>, fn)
  

• Chunk.chunks/parents/blocks 不再是数组。在内部使用一个集合，并且有方法来访问它。
• Parser.scope.renames 和 Parser.scope.definitions 不再是对象/数组，而是Map/Set。
• 解析器使用 StackedSetMap （类似于LevelDB的数据结构）而不是数组。
• 在应用插件时不再设置 Compiler.options 。
• 所有模块的构造参数都发生了变化。
• 将 options 合并到 ContextModule 和 resolveDependencies 的 options 对象中.
• 更改并重命名 import() 的依赖关系
• 将 Compiler.resolvers 移入可通过插件访问的 Compiler.resolverFactory 中。
• Dependency.isEqualResource 已被替换为 Dependency.getResourceIdentifier
• Template 方法都是静态的。
• 已经添加了一个新的 RuntimeTemplate 类， outputOptions 和 requestShortener 已经被移动到这个类中。

  RuntimeTemplate
  

• Module.meta已被Module.buildMeta所取代
• 已添加Module.buildInfo和Module.factoryMeta
• Module的一些属性已经被移动到新的对象中
• 添加指向上下文选项的 loaderContext.rootContext 。 loaders 可以使用它来创建相对于应用程序根目录的东西。
• 当启用HMR时，将 this.hot 标志添加到 loader 上下文中。
• buildMeta.harmony 已被替换为 buildMeta.exportsType：namespace 。
• chunk 图已经改变：
  • 之前：Chunks 的连接与嵌套依赖关系有关。
  • 现在：ChunksGroups 的连接与引用依赖有关，按照顺序串联。
  • 之前：AsyncDependenciesBlocks 按顺序引用 Chunks 列表。
  • 现在：AsyncDependenciesBlocks 引用一个 ChunkGroup。

★★ 注意：以上内容都是关于 loaders、plugins 重大的变化。

三、重点更新详解

3.1 更好的默认值

直到今日，webpack 总是要求显式地设置 entry 和 output 属性。webpack4 中，webpack 会自动设定你的 entry 属性为 ./src 以及 output 的属性为 ./dist 。 这意味着您 不再需要配置文件 来启动 webpack。接下来我们为你演示 webpack 4 的便捷操作：

1、我们需要安装好 webpack 之后，在 package.json 中添加如下脚本即可启动：

"scripts": {
    "build": "webpack"
  },
复制代码

2、在工程中添加简单示例代码如下图（整个工程没有 webpack 配置文件，即可运行打包）：

(图1，图中示例代码为 webpack3 官网示例)

3、打包过程中我们发现有新特性的提示：

WARNING in configuration
The 'mode' option has not been set. Set 'mode' option to 'development' or 'production' to enable defaults for this environment. 
复制代码

这就是我们下节要说的内容 模式设置 。

★★ 注意：入口默认为 ./src 如果缺少此文件夹会报错！

> webpack --mode production

ERROR in Entry module not found: Error: Can't resolve './src' in 'D:\workspace\github\Webpack-Example'
复制代码

3.2 模式设置

以往的项目使用 webpack3 脚手架生成项目初始模板都会有两个甚至三个配置文件，比如 webpack.base.conf.js 、 webpack.prod.conf.js 、 webpack.dev.conf.js 而现在可以做到一个配置文件都不需要，直接在启动命令中传入参数 --mode development | production 达到区分不同模式的效果。

接下来修改 package.json 设置不同的模式：

"scripts": {
    "dev": "webpack --mode development",
    "build": "webpack --mode production"
  },
复制代码

重新执行 npm run dev 或 npm run build 即可看到不同的打包结果：

我们可以看到两种模式的结果完全不同，下面我们会更深入的按照我们真实的需求来讲解一些常用配置。

接下来这个配置是最常用到的，我们使用 webpack 的主要目的之一就是为了更好的支撑前段模块化的能力，既然需要模块化当然少不了代码分割，目前代码分割有以下几种：

1. 通过 entry 分割不同入口，常用于多页应用；
2. 通过 CommonsChunkPlugin 插件来分割不同功能模块；
3. 通过动态 import 来分割。 下面我们主要讲解 webpack 4 版本的重大变化删除了 CommonsChunkPlugin 插件。

3.3 删除 CommonsChunkPlugin

webpack 4 删除了 CommonsChunkPlugin ，以支持两个新的选项（ optimization.splitChunks 和 optimization.runtimeChunk ）。

从 4.0 开始分割 Chunk 将不在使用 CommonsChunkPlugin 插件，而是使用 optimization 配置项，具体的实现原理可以参考： gist.github.com/sokra/1522d…

由于还没有正式官方文档出来，以下是我们通过实践出的 optimization 配置方法： 其中用到了新增的 splitChunks 属性，此属性看字面意思就明白是分割代码块的选项，其下可配置项已在下面示例代码中列出（有兴趣的朋友可以自行实践）：

entry: {
  vendor: ['lodash']
},

...

optimization: {
    splitChunks: {
      chunks: "initial",         // 必须三选一： "initial" | "all"(默认就是all) | "async" 
      minSize: 0,                // 最小尺寸，默认0
      minChunks: 1,              // 最小 chunk ，默认1
      maxAsyncRequests: 1,       // 最大异步请求数， 默认1
      maxInitialRequests : 1,    // 最大初始化请求书，默认1
      name: ()=>{},              // 名称，此选项课接收 function
      cacheGroups:{                 // 这里开始设置缓存的 chunks
        priority: "0",              // 缓存组优先级
        vendor: {                   // key 为entry中定义的 入口名称
          chunks: "initial",        // 必须三选一： "initial" | "all" | "async"(默认就是异步) 
          test: /react|lodash/,     // 正则规则验证，如果符合就提取 chunk
          name: "vendor",           // 要缓存的 分隔出来的 chunk 名称
          minSize: 0,
          minChunks: 1,
          enforce: true,
          maxAsyncRequests: 1,       // 最大异步请求数， 默认1
          maxInitialRequests : 1,    // 最大初始化请求书，默认1
          reuseExistingChunk: true   // 可设置是否重用该chunk（查看源码没有发现默认值）
        }
      }
    }
  },
复制代码

以上就是 optimization.splitChunks 的所有可用的配置项属性。

总结

以上就是我们初步整理的关于 webpack 4 的新特性，包含了一部分的官方更新日志的翻译，还有我们自己试验的一些属性。当然如果你有兴趣，也可以等到正式的官方文档发布之后进行实践。

如果上面的信息不能够完全满足你的兴趣，还请关注官方日志。在未来不到一个月的时间里，webpack 将对插件、加载器以及整个生态系统进行更加严格的测试，并发布最终的官方稳定版本。如果你喜欢 webpack，你可以参与使用 webpack4.0.0.beta，如果提出的问题越多，便可以为大家提供更加稳定的版本。