webpack 4.0.0-beta.0 新特性介绍

时间:2023-07-16 08:35:14

webpack 可以看做是模块打包机。它做的事情是:分析你的项目结构,找到JavaScript模块以及其它的一些浏览器不能直接运行的拓展语言(Scss,TypeScript等),并将其打包为合适的格式以供浏览器使用。目前,webpack 总共发布了三个稳定版本。从17年八月底开始,经历了长达五个月的开发周期,webpack 团队通过增加大量新特性、bug修复、问题改善并于近期发布了 webpack 4.0.0 的 beta 版本。如果你对 webpack 感兴趣,下面我们就来学习一下 webpack 4.0.0-beta.0 的新特性。 
P.S. 以下所有代码演示代码都是基于 webpack 4.0.0-beta.0。

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

如果你使用yarn:

yarn add webpack@next webpack-cli --dev

如果你使用npm:

npm install webpack@next webpack-cli --save-dev

2、webpack 4.0.0.beta.0 新特性介绍

下面是一些你肯定会感兴趣的新特性。如果阅读完本章后还觉得不过瘾,你可以再这查看完整的 changelog。 
本章将从以下几部分来介绍 webpack 4.0.0-beta.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 : (webpack3中默认)支持所有的JS模块系统:CommonJS、AMD、ESM。
  • javascript/esm : EcmaScript模块,所有其他模块系统不可用(.mjs文件中默认)。
  • javascript/dynamic : 不支持CommonJS和EcmaScript模块。
  • json : JSON数据,可以通过require和import导入(.json文件默认)。
  • webassembly/experimental : WebAssembly模式(目前处于实验性阶段,.wasm文件默认)。

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

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

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

javascript/esm 相比于 javascript/auto 处理ESM更加严格: 
具体表现在两个方面:1. 导入的名称必须存在于导入的模块中。2. 动态的模块(非ESM,例如CommonJS)只能通过默认 import 导入,其他所有(包括命名空间导入)的导入都会报错。

2.3 用法

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

2.4 配置

  • 删除了一些常用内置插件: 
    1)NoEmitOnErrorsPlugin -> optimization.noEmitOnErrors (生产模式默认)。 
    2)ModuleConcatenationPlugin -> optimization.concatenateModules (生产模式默认)。 
    3)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 优化

  • uglifyjs-webpack-plugin 升级到了 v 1,并且支持 ES6语法。
  • 可以在 package.json 中配置 sideEffects:false 。当设置这个字段之后,标识在使用的库里没有任何副作用。这意味着webpack可以从代码中安全地清除任何re-exports。
  • 使用JSONP数组来代替JSONP函数 –> 异步支持。
  • 引入新的 optimization.splitChunks 选项。
  • webpack 可以删除无用代码,之前是由 Uglify 删除无用的代码,现在 webpack 也可以删除无用的代码。这可以有效防止在 import 无用的代码之后发生的崩溃。 
    以下是一些内部优化: 
    1)用 tap 调用替换 plugin 调用(新的插件系统)。 
    2)将许多废弃的插件迁移到新的插件系统API。 
    3)为 json 模块添加 buildMeta.exportsType:default。 
    4)删除了 Parser (parserStringArray, parserCalculatedStringArray) 中未使用的方法。

2.6 性能

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

2.7 不兼容的改变(插件、loader相关)

  • 新的插件系统: 
    1)插件方法是向后兼容的 
    2)插件现在应该这样使用 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 已经被移动到这个类中。 
    1)已经更新了许多方法来代替 RuntimeTemplate 的使用。 
    2)我们计划将访问运行时的代码移动到这个新类中
  • 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、重点更新详解

3.1 更好的默认值

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

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

"scripts": {
    "build": "webpack"
},

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

webpack 4.0.0-beta.0 新特性介绍

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 4.0.0-beta.0 新特性介绍 
我们可以看到两种模式的结果完全不同,下面我们会更深入的按照我们真实的需求来讲解一些常用配置。

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

  • 通过 entry 分割不同入口,常用于多页应用;
  • 通过 CommonsChunkPlugin 插件来分割不同功能模块;
  • 通过动态 import 来分割。

下面我们主要讲解 webpack 4.0.0-beta.0 版本的重大变化删除了 CommonsChunkPlugin 插件。

3.3 删除 CommonsChunkPlugin

webpack 4.0.0-beta.0删除了 CommonsChunkPlugin ,以支持两个新的选项( optimization.splitChunks 和 optimization.runtimeChunk)。

从webpack 4.0.0-beta.0 开始分割 Chunk 将不在使用 CommonsChunkPlugin 插件,而是使用 optimization 配置项,具体的实现原理可以参考CommonsChunkPlugin

由于还没有正式官方文档出来,以下是我们通过实践出的 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(){}, // 名称,此选项可接收 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 的所有可用的配置项属性。